C++ Builder
| Главная | Уроки | Статьи | FAQ | Форум | Downloads | Литература | Ссылки | RXLib | Диски |

 
где выполнить логику, клиент или сервер
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, думаю, загнется. smile.gif

Есть такой опыт:
Бытовые абоненты городской электросети. 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, двухзвенка — определено заказчиком и изменению не подлежит.

Значит вам крупно не повезло с заказчиком.
А чем мотивирует? Может тем, что только это знает. wink.gif

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 не хочет sad.gif
QUOTE
А "под сотню" функций на С проще "вести"?

то, что выливается в сотню ХП на сервере, очень легко реализуется на клиенте. Отнюдь не сотня функций на C smile.gif 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 не хочет sad.gif

А лицензионный оракл есть бесплатный, правда с ограничением на число процессоров. И вообще — он хочет обсчитывать 200 тыс абонентов и иметь бесплатное ПО. Бросайте его — он жмот и у вас будут проблемы с оплатой собственного труда.


QUOTE (vvv40 @ 22.11.2006, 15:44)

Отнюдь не сотня функций на C smile.gif 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
Бросайте его — он жмот и у вас будут проблемы с оплатой собственного труда.

будем подумать smile.gif))
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 не даст такой изумительной возможности контроля транзакций, не даст возможности получения сообщений, не даст возможности прозрачной и удобной работы с генераторами.

универсализация — это хорошо, но только не в случае работы с СУБД. есть СУБД, есть ЕЁ особенности. всё это необходимо использовать по максимуму.

Вернуться в Работа с базами данных в C++Builder