Здравствуйте, уважаемые коллеги.
Есть приложение клиент-сервер для автоматизации в области ЖКХ. Написано на PowerBuilder 8, СУБД ASA 9.
В приложении реализована функциональность:
1. Расчет начислений и перерасчетов по услугам для населения: квартплата, мусор, отопление, горячая вода, холодная вода, стоки, электроэнергия.

2. Ручной ввод оплат за эти услуги, загрузка оплат из DBF-файлов (иногда текстовых и экселевских файлов) из банков (обычно у каждого банка своя структура DBF-файла), почты (УкрПочта), предприятий (удержание из зарплаты работников за коммунальные услуги), субсидий.

3. Внесение корректировок по лицевым счетам абонентов (изменения по площади, жильцам, временно выбывшим (армия, тюрьма, отпуск, временно работающие за границей, студенты на время обучения), тарифам, нормам, льготникам, типам собственности).

4. Разнообразные отчеты для бухгалтерии (большинство отчетов реализовано как DataWindow, но некоторые реализованы на FastReport+Delphi как отдельная утилита EXE, т.к. не все отчеты можно реализовать возможностями DataWindow).

5. Обмен данными с отделом субсидий и УТСЗН (Управление Труда и Социальной Защиты Населения) через DBF-файлы - выгрузка льгот для УТСЗН в DBF-файлы указанной ими структуры (потом эти файлы обрабатываются программой ЕДАРП (Единый Державный Автоматизований Реестр Пільговиків)), обмен с отделом субсидий по тарифам, нормам, жильцам и льготникам.

6. Вход в систему пользователей под своим логином и паролем, несложный контроль прав пользователя (кто-то может делать только изменения по ЛС, кто-то только заносить оплаты, кто-то только делать перерасчеты, кто-то вводить показания и т.д.).

7. Внесение показаний по приборам учета (счетчикам отопления, гор. и хол. воды, электроэнергии) как в ручном режиме так и из DBF-файлов банков.
Заказчиками являются коммунальные предприятия, бывшие ЖЭКи, ОСМД (Общества Совладельцев Многоквартирных Домов), СЕЗы (Службы Единого Заказчика), управляющие компании.
Расчеты начислений, перерасчетов, загрузка и распределение оплат реализовано средствами СУБД с помощью хранимых процедур (ХП).
Импорт/экспорт данных реализован с помощью команд Interactive SQL - INPUT, OUTPUT.
Все пользователи созданы прямо в БД.
Для соединения с БД используется ODBC.
Обычно у заказчика выделяется мощный компьютер для БД, для рабочих мест выделяются более слабые компьютеры (некоторые всего с 128 МБ ОЗУ), используется ОС Windows (98, 2000, ХР, 7). Поэтому не всегда толстый клиент шустро работает на таких машинах. При обновлении ПО нужно обновлять все клиентские компьютеры, что не всегда удобно, т.к. часто у заказчиков своих админов нет. Часто заказчики хотят для каждого пользователя свое личное меню в приложении в зависимости от своих прав, это не реализовано. Тоже касается и внешнего вида справочников, редакторов, отчетов (например: 1) бухгалтер по мусору открывая карточку лицевого счета не хочет видеть информацию о площади, нормах по воде, тарифах по другим услугам. 2) похожие отчеты приходится дублировать, т.к. один заказчик хочет видеть один набор колонок, а другой заказчик эти же колонки, но без последней, или те же колонки, но не в таком порядке). Не реализован некий мастер-отчетов, используя который пользователь смог бы создать нужный ему отчет на основе некоторого шаблона. Или один и тот же отчет по подходит нескольким заказчикам, но один заказчик хочет, чтобы сортировка в отчете была по адресу, а другой - по лицевым счетам (была попытка реализовать это показом окна с полями для сортировки, где пользователь мог выбрать необходимые поля для сортировки, но поля там все по английски, как и в самом запросе селект или ХП они названы). Да и сама сортировка не на стороне БД, а на стороне клиента при столь слабых машинах с 128 МБ ОЗУ тормозила.
Используется несколько вариантов инсталляции приложения:

1. EXE и PBD файлы, ODBC источник и Interactive SQL на каждой клиентской машине.

2. EXE и PBD файлы на машине, где крутится БД, в общей папке, на клиентских машинах вызывается EXE с компьютера, где крутится БД, ODBC источник и Interactive SQL на каждой клиентской машине.

3. EXE и PBD файлы на машине, где крутится БД, в общей папке, на клиентских машинах настроен удаленный рабочий стол, который подключается к машине, где крутится БД.
Сопровождением, программированием и обновлением данного приложения занимался 1 человек.
В связи с увеличением кол-ва заказчиков, их пожеланиями в добавлении нового функционала и исправления существующих недостатков на работу был взят еще один программист в помощь тому 1 человеку. Новый программист (джавист) имеет за плечами большой опыт работы с Java, 3-х уровневыми приложениями с использованием серверов приложений (СП), различными доступными фреймверками, неплохо разбирается в SQL, администрировании. Он часто повторяет слова: Java, Сервер приложений, фреймворк, новые технологии. За неимением такого опыта возразить ему трудно.
На этом форуме был топик с обсуждением 3-хзвенки .
На счет этого джавист сказал следующее:
авторДействительно странные. Тем более что это было в 2003 году. Сейчас таких странных мыслей уже ни у кого не возникает.
3х уровневое приложение это как минимум стандарт для больших приложений.

Теперь рассматривается возможность переписывания приложения под 3-хзвенку с такими пунктами:

1. Будет тонкий клиент (ТК), сервер приложений (СП) и сама СУБД.

2. ТК без проблем будет работать на слабых машинах с 128 МБ ОЗУ.

3. СУБД будет хранить только данные и индексы, использоваться как хранилище данных, вся бизнес-логика (то что сейчас делается на ХП, триггерах и функциях и работает довольно быстро - расчеты, отчеты, права пользователей) будет перенесена на СП (страшно представить во сколько раз увеличится время расчета начисления по горячей воде, если считать все это на Java, сейчас 10 тыс. лицевых счетов начисляются за 10-15 мин с помощью ХП, и эту ХП еще можно оптимизировать).

Как например оптимизировал расчет начисления заработной платы и приводил свои рекомендации и советы на этом форуме ASCRUS.
У него 1000 сотрудникам зарплата начислялась на ХП всего за 8 сек - отличный результат.

Нашего джависта время расчета не пугает, главное, чтобы считалось правильно.

4. На СП на Java будет использоваться стандарт ANSI-SQL 99, чтобы СП мог поддерживать в будущем не только СУБД ASA 9, но и другие СУБД (FireBird, PostgreSQL и т.д.), т.е. не привязываться к возможностям расширений SQL конкретной СУБД.

5. Пользователей, их права и роли перенести на СП, в БД будет только 1 пользователь.

6. На СП будет реализована возможность занесения показаний контролером через мобильное устройство, использующее современные ноу-хау (например пришел контролер в квартиру с мобильным устройством, снял показания, внес их на клавиатуре своего устройства и они успешно передались в БД).

6. На СП будет реализована возможность отправки смс на мобильный и автодозвон на телефон абонента (мобильный, рабочий, домашний) с информацией о задолженности за коммунальные усулги и т.п..

7. На СП будет реализована возможность импорта/экспорта XML-файлов в/из БД (есть надежда, что DBF формат скоро умрет и вместо него для общения с банками, организациями, УТСЗН будет использоваться формат XML).

8. На СП будет реализована возможность поддержки веб-интерфейса для абонентов (например абонент дома при наличии интернета зашел на сайт коммунального предприятия под своим логином и паролем, где может посмотреть информацию о своих долгах/переплатах за коммунальные услуги, начислениях и оплатах, а не идти вместо этого в ЖЭК на сверку).

Прошу высказаться уважаемых коллег по всему вышенаписанному. Любая критика, советы, рекомендации, реальные примеры успешных переводов на новую 3-х уровнемую технологию приветствуются. Всем спасибо за внимание.

авторЧто мешает использовать существующие процедуры написав к ним WEB-интерфейс?

Ничего не мешает. Тот же СП может вызвать ХП, как это сейчас и делает приложение на PowerBuilder.
Джавист мотивирует перенос расчетов с SQL на Java тем, что хоть и можно написать расчет на SQL, но он для этого не предназначен, в отличие от высокоуровневых языков типа Java. Или возможно ему трудно самому дописывать/переделывать расчеты на SQL.

авторТонкий клиент будет жить в браузере?
Нет, не в браузере. Предполагается, что ТК - это будет легкое приложение на Java, которое будет только отображать справочники, редакторы и отчеты, которые в свою очередь будут формироваться СП. Хотя для этого на слабой машине со 128 МБ ОЗУ должна быть установлена виртуальная Java машина, которая тоже требует ресурсы ОЗУ. И эти затраты ОЗУ предположительно будут меньше затрат ОЗУ, которые использует PowerBuilder для интерпретации библиотек PBD.
авторА такое требование действительно существует где-то, кроме воображения вашего нового коллеги?
Пока еще не было заказчиков, у которых была своя СУБД, отличная от ASA, но все может быть. Вполне возможно, что появится заказчик, который захочет, чтобы БД была бы например на FireBird или на какой-нибудь другой СУБД.
Тут 2 варианта:
1. Весь функционал, который реализован на SQL сейчас для ASA перевести на FireBird и далее поддерживать реализацию для обеих СУБД.

2. Написать функционал на ANSI SQL 99 так, чтобы он работал как на ASA, так и на FireBird.
авторОчередной велосипед с квадратными колесами.
Когда будет создан сайт, куда любой абонент сможет войти со своим логином и паролем, предполагается хранить этих юзеров не в БД, а на СП, ведь таких юзеров может быть столько же, сколько и лицевых счетов в БД, и каждому такому юзеру нужно дать права на просмотр только своих данных.

авторПопросите джависта (а лучше независимого) оценить объем работ, а потом покажите это тому кто будет оплачивать эти работы.
Джавист говорит, что он сам напишет сервер приложений на Java за полгода.

To PL99:
авторПоинтересуйтесь, какую платформу или набор библиотек компонентов он предпочитает
Eclipse. Spring Framework.
авторПопросите предоставить обоснование. Лучше всего, в виде исполняемого кода.
Сам хотел бы посмотреть на это чудо программирования на Java.
авторЯ не знаком с SQL и не собираюсь его изучать
Есть такое дело, он не очень любит SQL.
авторЕдинственно правильный подход, если это экономически целесообразно, использовать вариант 1. Сами-то верите, что вариант 2 возможен?
Если и придется поддерживать несколько СУБД, то больше склоняюсь к варианту 1.
Имеется ввиду, что варианте 2 будут использоваться только стандартные SQL операторы: Select, Insert, Update, Delete.
авторЭто решается немножко другими средствами.
Если не секрет, подскажите какими ?
авторПопробуйте. Не забудьте через полгода рассказать о результатах.
Джавист преисполнен энтузиазма и готов к нападению жуткого работуна. О результатах работуна через полгода обязательно доложу.

spas2001PL99пропущено...
Попросите предоставить обоснование. Лучше всего, в виде исполняемого кода.

Не будут, проверено
Есть подозрения, что при 128 МБ ОЗУ клиент на Java может вообще не запуститься.
Сама среда разработки Eclipse загружается очень долго на его рабочем компьютере, где памяти побольше.

Локшин Маркlionerпропущено...

Есть такое дело, он не очень любит SQL.

На java очень любят ОРМ и судя по озвученному он там будет. Но хороший ОРМ так никто пока и не придумал (чтобы хоть как-то по скорости с native SQL конкурировало). Да, в некоторых случаях удобно работать с базой, как с классами. Но чуть отступаешь от примеров типа Hello World и понимаешь, что без ОРМ гораздо веселее.
Библиотека Hibernate позволяет отобразить каждую таблицу БД в отдельный класс на Java. При этом джависту не обязательно знать SQL, он будет работать с этими обьектами, а те в свою очередь с помощью своих методов посылать SQL-запросы в базу. Очень удобно, но работает медленнее чем на уровне SQL.

pandTo lioner :

извините если я совсем не по теме.

Такие проекты хорошо затевать в бюджетных организациях. Бюджету можно напилить прилично.

А если к Вам через полгода в помощь программистам нужен будет третий ( а он таки будет нужен ) и он окажется лихим спецом по .net можете начинать экранизацию басен дедушки Крылова.

Всегда думал что владелец ( работодатель) диктует правила написания кода.
Да Powerbuilder не модный нынче язык , но я не поверю что задача автоматизации в области ЖКХ поставит его в тупик.

Возможно вам нужно модернизировать ваш билдеровский фреймворк , который у вас наверняка существует.

В общем удачи Вам. и ждем новостей через полгода .

В существующем приложении действительно хватает ошибок и багов, они исправляются с помощью очередных костылей и велосипедов, поэтому джавист предлагает полность все переписать правильно. Большинство нюансов, тонкостей и подводных камней в предметной области ЖКХ уже известны, в отличие от того времени, когда начинался писаться существующий проект.

Филиппlionerпропущено...

Джавист говорит, что он сам напишет сервер приложений на Java за полгода.

Это значит, что ни единому его слову доверять нельзя, и по возможности от него нужно избавиться :-)))
Сколько по вашему занимает времени написание приложения с нуля на Java для работы с БД, с учетом того, что предметная область и бизнес-логика уже хорошо изучены на практике существующего приложения ?

medoedВставлю свои 5-ть копеек. Не забываем о сервере приложений. Как правило это отдельный компьютер (сервер) с хорошим процом и оперативкой. Также надежность системы немного уменьшается, так как появляется 3-е звено, сервер приложений от сети отрубится и усе...
Толстоту клиента можно уменьшить, пененеся часть логики на сервер СУБД, но нужно понимать, что тут четкая должна быть документируемость проекта и доступна база средствами проектирования, PowerDesiner например. Насчет неудобства обновления, вы можете часть компонент отрисовывать динамически, в базе хранится, не только сам код sql для datawindow но и способ отрисовки самого отчета. Конструктор присобачить, чтобы сам программист не лазил в код, а конструировал сам отчет с помощью конструктора.
О библиотеках проекта и их версии, можно хранить инфу в самой базе, тогда при работе пользователя например раз в 3 часа при несовпадении версии - предупреждать о необходимости обновления. Обновление должно проверяться автоматом при старте приложения и обновляться, как вариант, с сети, куда программист выкладывает исходники.

Спасибо за советы, примем к сведению.

spas2001Я же говорю, что он настоящий русский программист
Улыбнуло :-)

PL99Вы пробовали?
Нет, не пробовал, с Java не работал. Удобно в том смысле, что можно работать с БД, не владея навыками SQL.
PL99Речь идет об одном и том же человеке?
Да, об одном и том же человеке, который неплохо разбирается в SQL, но не очень его любит использовать, когда дело касается расчетов.

spas2001Называйте вещи своими именами - вообще не разбирается в SQL и не знает реляционную алгебру.
Мало того, не знает и не хочет узнавать, прикрываясь словами, что все надо сделать универсально
Не совсем так. Джавист вник в создание окон в PowerBuilder, возможности PowerScript и DataWindow, как создавать отчеты, написал несколько ХП с расчетами (несколько перерасчетов и распределение оплат по услугам, когда абонент оплачивает одной суммой за несколько услуг). Правда эти ХП работают медленно и нужно их оптимизировать (например 1000 оплат распределяются около 15 минут). Просто он привык программировать, работая с обьектами, используя ООП, а ХП на SQL - это процедурное программирование, а не обьектно-ориентированное.

Локшин МаркА как он будет работать только с объектами, мне вот интересно? ОРМ обертка обеспечивает CRUD операции с объектами. Но далеко не все можно выразить в терминах намепленных сущностей - по сути это возврат к сетевой/иерархической модели данных. Для того, чтобы было не все так печально придумали HQL - по сути весьма урезанный SQL и CriteriaQuery - урезанный HQL в объектно-ориентированной обертке. Ввиду этого весьма странно было бы не знать SQL. Это не касаясь вопросов изменения схемы данных и прочего с этим связанного.
Опишу как я понял со слов джависта простой расчет для одного лицевого счета:
Есть 2 таблицы:
account - лицевые счета

tarif - тарифы
Таблица account:
ЛСОбщая площадьТарифная схема100052.701
Таблица tarif:
Тарифная схемаКод услугиТариф112.50
Т.е. у ЛС № 1000 общая площадь=52.70м2 и тариф=2.50грн.
Начисление = 52.70 * 2.50 = 131.75 грн.
Расчет на SQL:


На Java будет 3 обьекта:

account - лицевые счета

tarif - тарифы

doc - документы с начислениями
Обьект account методом GetValue получает значение св-ва area, обьект tarif методом GetValue получает значение св-ва tarif, перемножает, и рез-т присваивает св-ву SUM обьекта doc, тот в свою очередь сохраняет эту сумму в таблицу DOC.
Это самый упрощенный вариант конечно.

Anatoly Moskovskylioner1000 оплат распределяются около 15 минут
Зато какое пространство для оптимизаций
Да, там несколько курсоров, много проверок. Если убрать курсоры и заменить на инсерты во времянки, а потом их обьединения, то будет значительно быстрее.

rolekslioner, Вы, случайно, не из Житомира?
Нет, из Донецка.
medoedФилипппропущено...
Как минимум в 3 раза дольше чем на РВ :-)
Пожалуй подпишусь, в простейших случаях, если субд сама не упакована в классы, что порой удобно для наследования, то dw уделает любую ORM.
ORM решили для расчетов не использовать, ХП с расчетами останутся.