| vvv40 |
| Отправлено: 22.11.2006, 13:39 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 8
|
Задача довольно традиционная. БД на FireBird 1.5, клиент на BCB6.
База для организации типа ГорГаз, ГорСеть, ГТС на 200 тыс. абонентов.
Требуется произвести перерасчет каждого абонента, расчитывая каждый месяц (за три года), учитывая тарифы, ставки, льготы, пени и т.д.
В теории надо конечно это организовать в виде ХП на сервере. Но есть большое желание все это посчитать на клиенте, очень уж скромные возможности SQL для FireBird. Получается громоздкая, малопонятная конструкция из множества ХП, придется постоянно использовать курсоры (, одни и те же значения из справочников постоянно Select'ами дергать.
На клиенте же все можно сделать просто, понятно, отладка проще, время на разработку на порядок меньше. IMHO скорость в результате будет выше.
Возможности UDF dll тоже сильно ограничены.
Может кто что посоветует ?
|
|
| AVC |
| Отправлено: 22.11.2006, 14:11 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE | Может кто что посоветует ?
|
Сменить сервер.
Перенося бизнес логику на клиента вы предлагаете использовать БД просто как хранилище данных. Для двухзвенки это очень "скользкое" решение. Другое дело если вы будете делать трехзвенную систему.
| QUOTE |
База для организации типа ГорГаз, ГорСеть, ГТС на 200 тыс. абонентов.
Требуется произвести перерасчет каждого абонента, расчитывая каждый месяц (за три года), учитывая тарифы, ставки, льготы, пени и т.д.
|
FB, думаю, загнется. 
Есть такой опыт:
Бытовые абоненты городской электросети. 60тыс. Расчет начиная с 1.1.2000. Сервер БД — Oracle. Построение — псевдо трехзвенка. Сервер БД и сервер приложений совмещен (благо Oracle это легко позволяет). Вся бизнеслогика на сервере. |
|
| olegenty |
| Отправлено: 22.11.2006, 14:30 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
поддерживаю AVC. я тоже стараюсь всю логику реализовывать на сервере БД. есть, правда, ряд проверок, которые приходится выполнять на клиенте, но в этом случае параметры для этих проверок должны всё равно браться с сервера а код проверок должен быть универсальным настолько, чтобы любое изменение параметров проверки на сервере не приводило к необходимости модификации кода клиентской стороны (встречается в различных элементах GUI).
|
|
| vvv40 |
| Отправлено: 22.11.2006, 15:17 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 8
|
FireBird, двухзвенка — определено заказчиком и изменению не подлежит. Именно поэтому и возник вопрос. В случае трехзвенки, естественно, логику — на сервер приложений. В случае двухзвенки с MSSQL я бы логику на сервере, конечно, написал. А в моем (запущеном) случае:
- FB нагрузку выдержит, но дополнительно логикой нагружать, наверное, не стоит. Все-таки это не Oracle/MSSQL.
- слишком “куцые” возможности FB для написания логики. Получается под сотню хранимок, разобраться в которых сложно. С точки зрения сопровождения — гуманнее переписать клиента
- скорость работы, наверное, с логикой на клиенте будет выше.
А с другой стороны, основы “клиент-серверных” технологий нарушать не хочется. Вот и подсчитываю все +/-.
|
|
| olegenty |
| Отправлено: 22.11.2006, 15:23 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
насчёт куцых — согласен, но писать надо на сервере. а скоро и FB2 выйдет — всё полегче будет, там функционал существенно расширен.
|
|
| vvv40 |
| Отправлено: 22.11.2006, 15:32 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 8
|
А если посмотреть в сторону трехзвенки, то в данном случае (FB + BCB6), сервер приложений как бы стоило реализовать ? |
|
| AVC |
| Отправлено: 22.11.2006, 16:07 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE (vvv40 @ 22.11.2006, 14:17) | FireBird, двухзвенка — определено заказчиком и изменению не подлежит.
|
Значит вам крупно не повезло с заказчиком.
А чем мотивирует? Может тем, что только это знает. 
| QUOTE (vvv40 @ 22.11.2006, 14:17) |
...но дополнительно логикой нагружать, наверное, не стоит. Все-таки это не Oracle/MSSQL.
- слишком “куцые” возможности FB для написания логики. Получается под сотню хранимок, разобраться в которых сложно.
|
Это не оправдание. А "под сотню" функций на С проще "вести"?
Нет. Логику — на сервер. |
|
| AVC |
| Отправлено: 22.11.2006, 16:16 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Для справки
В среднем 169 записей событий на абонента
Среднее время полного пересчета абонента 0.4931 s
Это на 2-х ядерном Entry с SCSI RAID
|
|
| vvv40 |
| Отправлено: 22.11.2006, 16:44 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 8
|
| QUOTE | Значит вам крупно не повезло с заказчиком.
А чем мотивирует? Может тем, что только это знает. |
Деньги. FB — бесплатно. Нелицензионный SQL Server не хочет 
| QUOTE | | А "под сотню" функций на С проще "вести"? |
то, что выливается в сотню ХП на сервере, очень легко реализуется на клиенте. Отнюдь не сотня функций на C Select'ами вытаскиваем все данные по абоненту и используя нормальный язык и в рамках ООП логично и прозрачно все описываем и обсчитываем.
Может действительно попробовать посмотреть в сторону сервера приложений ? COM+ ? но с точки зрения написания/сопровождения — внутри будет тот же код для реализации расчета, что и был бы на клиенте.
Плюсы в скорости ? и то вряд ли
| QUOTE | Для справки...
Среднее время полного пересчета абонента 0.4931 s |
а не многовато ? 60 тыс.абон. — 8 часов однако
|
|
| AVC |
| Отправлено: 22.11.2006, 17:27 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE (vvv40 @ 22.11.2006, 15:44) |
Деньги. FB — бесплатно. Нелицензионный SQL Server не хочет
|
А лицензионный оракл есть бесплатный, правда с ограничением на число процессоров. И вообще — он хочет обсчитывать 200 тыс абонентов и иметь бесплатное ПО. Бросайте его — он жмот и у вас будут проблемы с оплатой собственного труда.
| QUOTE (vvv40 @ 22.11.2006, 15:44) |
Отнюдь не сотня функций на C Select'ами вытаскиваем все данные по абоненту и используя нормальный язык и в рамках ООП логично и прозрачно все описываем и обсчитываем.
|
А если работет насколько человек, а как придется передавать, а головная боль с контролем и распространением версий, да мало ли какие еще грабли вылезут. Как раз на сервере все прозрачно — единое место кода, прав, доступа.
| QUOTE (vvv40 @ 22.11.2006, 15:44) |
а не многовато ? 60 тыс.абон. — 8 часов однако
|
Что поделать, такова правда жизни.
| CODE |
Статистика пересчетов
Начало Конец Абонентов s на абон Часов Ошибок
вт 21.11.2006 19:16 21.11.2006 22:22 59923 0.1864 3:06:10
пн 20.11.2006 19:16 20.11.2006 22:38 59923 0.2023 3:22:02
пт 17.11.2006 18:46 18.11.2006 3:13 59916 0.4931 8:26:40
чт 16.11.2006 19:16 16.11.2006 22:48 59896 0.2121 3:31:43
ср 15.11.2006 19:16 15.11.2006 22:37 59885 0.2014 3:21:00
|
Среди недели короткий пересчет, на выходных полный.
|
|
| olegenty |
| Отправлено: 22.11.2006, 17:34 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 vvv40 а ты думаешь, расчет на клиенте сможет с этим конкурировать??? ну попробуй, поэкспериментируй. только стянуть данные на клиента для расчета займёт больше времени. причём это не имхо, а факт. для расчёта серверу надо мало — входные параметры, и клиенту мало — выходные параметры. а для расчёта на клиенте надо иметь локальную копию кучи таблиц на клиенте. смешная базёнка в 8 Гб размером не в любой своп влезет, несколько часов ждать придётся... а дальше либо всё просто зависнет (это если всё-таки влезет в своп), либо несколько суток/недель ожидания расчёта, который весь будет состоять из операций чтения/записи свопа... клиент серверные СУБД затем и созданы...
насчёт сервера приложений. а времени хватит? задача-то нетривиальная... сервер приложений — штука не тупая и плоская, а очень многопоточная и продуманная...
|
|
| olegenty |
| Отправлено: 22.11.2006, 17:39 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
касаемо FB — СУБД потянет достаточно легко таблицы весом порядка единиц миллионов записей. на большем не пробовал. по отношению к MSSQL — FB не блокировочник, это премиущество. при конкурентной работе MSSQL очень неповоротлив, либо немеряные деньги надо грохать в сервер. но у FB скудный язык на стороне сервера. хотя, уже наконец-то добавились подзапросы, и, возможно, временные таблицы. уже лучше, чем ничего (хотя за временные не отвечаю).
если будешь работать с FB — раскошелься на FIBPlus однозначно — лучшей прослойки для доступа к FB нет в природе. и стоит недорого.
|
|
| AVC |
| Отправлено: 22.11.2006, 17:40 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Да, еще примите во внимание следующее: Если бизнеслогика на клиенте, то законектившись к базе НЕ ЭТИМ клиентом я могу легко разрушить целостность базы. |
|
| olegenty |
| Отправлено: 22.11.2006, 17:54 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Зачитал, что поддерживает Firebird 2.0 из стандарта SQL. Не, нафиг, лучше, чем FB 1.5, но смешно по отношению к прочим. Вообще при большой базе я б на Oracle остановился. Мечтаю освоить — MSSQL достал своей блокировочной архитектурой и убогостью ряда конструкций TSQL (хотя он и на порядок-другой богаче FB).
|
|
| olegenty |
| Отправлено: 23.11.2006, 07:56 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
ещё (в дополнение к AVC)
у меня тоже псевдо-трехзвенка, только хуже того, БД — псевдо объектная. т.е. связи между таблицами — реляционные, а вот между сущностями, которые в них хранятся — нет. чтение таблиц просто ничего не даст. наборы идентификаторов, кроме "таблиц листьев" с данными каждого объекта. по условиям задачи у тебя это может и не так, но вообще, мои юзеры о служебных таблицах ничего не знают. они получают и модифицируют данные только посредством ХП (реже — View)
таблиц — 77
просмотров — 72
хранимых процедур — 233
|
|
| vvv40 |
| Отправлено: 23.11.2006, 08:53 |
|
Ученик-кочегар
Группа: Участник
Сообщений: 8
|
| QUOTE | | Бросайте его — он жмот и у вас будут проблемы с оплатой собственного труда. |
будем подумать ))
| QUOTE | | А если работет насколько человек, а как придется передавать |
не понял что/куда передавать ?
| QUOTE | | , а головная боль с контролем и распространением версий, да мало ли какие еще грабли вылезут. Как раз на сервере все прозрачно — единое место кода, прав, доступа. |
с контролем и распространением, в моем случае, проблем нет. А вот будущие грабли пытаюсь разглядеть )
| QUOTE | | думаешь, расчет на клиенте сможет с этим конкурировать??? ну попробуй, поэкспериментируй. только стянуть данные на клиента для расчета займёт больше времени |
120 тыс.абонентов по 50 записей на каждого клиент засасывает 50 мин.
Мне же надо стянуть данные по одному клиенту, расчитать, записать. Потом по другому. Зачем целиком всю базу ? А справочники скачать один раз, чтобы их на клиенте использовать, не дергать сервер.
| QUOTE | | Если бизнес-логика на клиенте, то законектившись к базе НЕ ЭТИМ клиентом я могу легко разрушить целостность базы. |
В моем случае целостность не пострадает. Я говорю только про перерасчет. Выбираю данные, рассчитываю, записываю с помощью ХП.
Вся остальная бизнес-логика — на сервере. В худшем случае (клиент не той версии) данные неправильно расчитаются, но это контроль версий.
Я же не против основ технологии "клиент-сервер", я за логику на сервере, так всегда и стараюсь делать. У меня сомнения относительно данного конкретного случая, причем только относительно процедуры перерасчета.
| QUOTE | | раскошелься на FIBPlus однозначно |
с ним и работаю
кстати, а не пробовали с FB через ADO + OLE DB Provider for FB ?
интересно бы сравнить
| QUOTE | | насчёт сервера приложений. а времени хватит? задача-то нетривиальная |
наверное не стоит, действительно не все просто, а плюсов почти нет
|
|
| olegenty |
| Отправлено: 23.11.2006, 09:35 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
реализация ADO оставляет желать лучшего, в то время как FIBPlus — самое то. и, ADO не даст такой изумительной возможности контроля транзакций, не даст возможности получения сообщений, не даст возможности прозрачной и удобной работы с генераторами.
универсализация — это хорошо, но только не в случае работы с СУБД. есть СУБД, есть ЕЁ особенности. всё это необходимо использовать по максимуму.
|
|
