Какие именно задачи следует решать с помощью ХП?

← →
Игорь Шевченко © (2006-10-25 15:25) [40]

Курдль © (25.10.06 15:21) [38]

> Умеет оперировать объектами предметной области, как умеет
> это делать
> любой ООП - ЯВУ?

Эта...я очень извиняюсь, но ООП-ЯВУ не умеет манипулировать объектами предметной области даже по сравнению с сервером СУБД.

> Оракл - прекрасная СУБД. Но вовсе не потому, что у нее такой
> замечательный PL/SQL.

Да, у нее еще и Java есть. И объектно-реляционные возможности.

> А потому, что это чрезвычайно производительная и надежная
> СУБД, способная обрабатывать запросы от огромного числа
> пользователей к весьма объемным таблицам.

А если еще хранимыми процедурами на замечательном PL/SQL пользоваться, то в ряде случаев огромное число пользователей можно увеличить :)

← →
euru © (2006-10-25 15:31) [41]

> Игорь Шевченко © (25.10.06 15:20) [37]
> DiamondShark © (25.10.06 15:21) [39]

Если начнутся проблемы с производительностью сервера приложений, то всегда можно добавить ещё один сервер приложений, распределив нагрузку между ними.

> Если для работы сервера приложений требуется обмен с сервером
> базы данных, а хранимая процедура на сервере уменьшает объем
> этого обмена, то твой вариант разгрузки не приведет к выигрышу,
> а только к перемещению узкого места
Введение сервера приложений опять-таки может уменьшить объём передаваемых данных, потому что часто используемые данные хранятся на сервере приложений, и для обращения к ним не нужно ни загружать канал между сервером БД и сервером приложений, ни нагружать СУБД по их обработке.

← →
Игорь Шевченко © (2006-10-25 15:39) [42]

euru © (25.10.06 15:31) [41]

> Введение сервера приложений опять-таки может уменьшить объём
> передаваемых данных, потому что часто используемые данные
> хранятся на сервере приложений, и для обращения к ним не
> нужно ни загружать канал между сервером БД и сервером приложений,
> ни нагружать СУБД по их обработке.

Я наверное открою страшный секрет, если скажу, что сервер базы данных тоже хранит данные в кэше.

← →
Desdechado © (2006-10-25 15:40) [43]

euru © (25.10.06 14:29) [26]
> Руление правами и доступом надобно бы тоже перенести в бизнес-логику,
> потому что правила их применения могут быть привязаны не только к
> объектам БД, но и к бизнес-объектам.
Если бизнес-объект - прямое отображение сущности из БД, то в СУБД права раздать легче, тем паче что там для этого уже есть все средства.
Если бизнес-объект - это нечто, аккумулирующее в себе несколько хитрым образом связанных сущностей из БД, то права на него стоит раздавать в сервере приложений. (хотя тут может быть и ошибка проектирования, когда сущностии бизнес-объекты оказались разными, будучи по сути синонимами).
Но также следует помнить, что СУБД - это последняя инстанция проверки прав, когда ничто другое не помогло. Например, при подключении к БД напрямую минуя хитрые сервера приложений с их навороченной логикой защиты.

> kaif © (25.10.06 14:42) [30]
> 1. Писать трехзвенки, когда двухзвенок почему-то оказывается всегда достаточно.
> 2. Пренебрегать богатейшими возможностями определенного сервера и
> вместо этого реализовывать руками в приложении (пускай серверном!)
> то, что сервер уже и так умеет делать.
> 3. Платить за функционал сервера, который заведомо не хочу использовать.
Эти эмоции имеют смысл, когда сам решаешь, в какой архитектуре будешь работать. Если же у тебя на руках ТЗ заказчика, в котором сказано "многозвенка под СУБД хххх", то п.1 и п.3 отпадают сразу.

← →
Игорь Шевченко © (2006-10-25 15:43) [44]

euru © (25.10.06 15:31) [41]

> Введение сервера приложений опять-таки может уменьшить объём
> передаваемых данных, потому что часто используемые данные
> хранятся на сервере приложений, и для обращения к ним не
> нужно ни загружать канал между сервером БД и сервером приложений,
> ни нагружать СУБД по их обработке.

И еще - как будет решена проблема консистентности данных, если "часто используемые данные" хранятся на сервере приложений и одновременно неким образом (например, сторонним средством или запуском штатного пакетного задания) изменяются на сервере базы данных ?

← →
kaif © (2006-10-25 15:46) [45]

2 Курдль ©

Я же сказал, что если речь идет о трехзвенках, то я бы придерживался именно такого похода: поменьше ХП.

Я недавно писал на JAVA сервлетное приложение под Tomcat + ORACLE для интранет.

И я решил всю задачу.
Настолько мне не понадобились ХП, что я даже и не стал изучать, как их делать в ORACLE.

Но заявлять, что использование ХП в двухзвенках означало бы нежелание думать над SQL-запросамиЮ, я бы не стал, даже если сошел бы с ума.

← →
Курдль © (2006-10-25 15:47) [46]

> Игорь Шевченко © (25.10.06 15:25) [40]
> Эта...я очень извиняюсь, но ООП-ЯВУ не умеет манипулировать
> объектами предметной области даже по сравнению с сервером
> СУБД.

Ага! Начинаем придираться к коряво сформулированным тезисам? :)
Это не конструктивно!

← →
kaif © (2006-10-25 15:48) [47]

Все WEB-приложения и приложения интранет по своей сущности - трехзвенки, если там есть хотя бы какой-нибудь динамический HTML.

← →
kaif © (2006-10-25 15:49) [48]

Потому в интернет всех победил MySQL.
Вот этот товарисч не умеет никаких ХП выполнять.
И Вопрос снимается сам собой.

← →
Курдль © (2006-10-25 15:51) [49]

> kaif © (25.10.06 15:48) [47]
> Все WEB-приложения и приложения интранет по своей сущности
> - трехзвенки, если там есть хотя бы какой-нибудь динамический
> HTML.

Я бы сказал "если там есть какой-нибудь вэб-сервер" :)

← →
euru © (2006-10-25 15:55) [50]

> Игорь Шевченко © (25.10.06 15:39) [42]
> Я наверное открою страшный секрет,
> если скажу, что сервер базы данных тоже хранит данные в
> кэше.

Хранит. Но этот кэш - общий для всех приложений, использующих СУБД. И если какое-либо одно приложение будет более активно в создании новых запросов, то оно просто вытеснит из кэша результаты запроса другого приложения, которое работает не менее активно, но в основном с одними и теми же данными.

← →
iZEN © (2006-10-25 15:56) [51]

>Какие именно задачи следует решать с помощью ХП?

Несложные. Без OR-Mapping. Там, где не требуется использование объектов.
ХП хорошо оптимизируются планировщиками SQL-серверов и выполняются заведомо быстрее остальных (сложных) SQL-запросов.

С приходом OR-Mapping SQL-сервера превратились в простые хранилища "плоских" данных, так как аппсервер взял на себя функции сериализации и десериализации объектов. Объекты легки для понимания обычными разработчиками, в отличие от сложных вопросов оптимизации запросов и языка БД. Поэтому есть смысл сосредоточится на серверной логике, чем на изобретении оптимальных ХП.

Кроме того, память, процессорное время, дисковое пространство стали гораздо дешевле труда программиста. Так зачем на них экономить и не применять аппсерверы? SQL-сервера теперь стали простыми "банками" с данными.

← →
Игорь Шевченко © (2006-10-25 16:00) [52]

euru © (25.10.06 15:55) [50]

> И если какое-либо одно приложение будет более активно в
> создании новых запросов, то оно просто вытеснит из кэша
> результаты запроса другого приложения, которое работает
> не менее активно, но в основном с одними и теми же данными.
>

Тем более не вытеснит. Часто используемые данные не вытесняются. Впрочем, все познается статистикой.

kaif © (25.10.06 15:49) [48]

> Потому в интернет всех победил MySQL.
> Вот этот товарисч не умеет никаких ХП выполнять.

"Исторически сложилось, что по частоте использования в Интернет-проектах MySQL идет на первом месте. Она идеально подходит для «наколенных» приложений"

http://www.babr.ru/news/print.php?IDE=6283

← →
ANB © (2006-10-25 16:02) [53]

> Кроме того, память, процессорное время, дисковое пространство
> стали гораздо дешевле труда программиста. Так зачем на них
> экономить и не применять аппсерверы? SQL-сервера теперь
> стали простыми "банками" с данными.

Так зачем на них экономит и не применять ХП ?. Ведь при их использовании таки значительно сокращается время на отладку.
3-х звенку придумали лентяи из MS, чтобы закрыть явные недостатки в серверной логике своего сервера.

← →
Игорь Шевченко © (2006-10-25 16:05) [54]

iZEN © (25.10.06 15:56) [51]

> Кроме того, память, процессорное время, дисковое пространство
> стали гораздо дешевле труда программиста. Так зачем на них
> экономить и не применять аппсерверы? SQL-сервера теперь
> стали простыми "банками" с данными.

Я конечно извиняюсь, но дешевизну памяти и процессорного времени лучше использовать для масштабируемости приложений.

← →
euru © (2006-10-25 16:11) [55]

> Игорь Шевченко © (25.10.06 15:43) [44]
> И еще - как будет решена проблема консистентности данных

Могу привести описание, как это сделано в SAP R/3.

Буферизация таблиц базы данных
Буферизация таблицы улучшает производительность при обращении к содержащимся в таблице записям.
Буферы таблиц хранятся локально на каждом сервере приложений системы. Поэтому данные буферизованных таблиц могут быть доступны непосредственно из буфера сервера приложений. Это позволяет избегать длительного по времени процесса обращения к базе данных.
Буферизация особо важна в средах клиент/сервер, так как в них доступ к таблице по сети значительно дольше доступа к локально буферизованной таблице. В зависимости от загрузки сети этот коэффициент может находиться в диапазоне от 10 до 100.
В центральных системах (системах с одним сервером приложений) различия в производительности несколько меньше, чем локальных (системах с несколькими серверами приложений). Однако даже в центральных системах сокращение процессов изменений и усовершенствованный механизм буферизации по сравнению с предоставляемым системой базы данных заметно влияет на производительность.

Как заполняются буферы?
Если программа обращается к данным буферизованной таблицы, интерфейс базы данных определяет, имеются ли эти данные в сервере приложений. Если имеются, то данные читаются непосредственно из буфера. Если данных в буфере сервера приложений нет, то они читаются из базы данных и загружаются в буфер. При дальнейшем обращении к этим данным может использоваться буфер.
Какие записи загружаются в буфер при обращении к ним, определяет тип буферизации.

Как синхронизируются локальные буферы?
Буферизованная таблица обычно считывается на все серверы приложений и хранится в их буферах. Если программа изменяет данные, содержащиеся в таблице на сервере приложений, то это фиксируется в журнале интерфейсом базы данных. На всех других серверах приложений буферы остаются в старом состоянии, так что программы могут прочесть устаревшие данные.
Через фиксированные интервалы времени, обычно 1-2 минуты, запускается механизм синхронизации. Происходит чтение журнала, после чего содержимое буфера, которое было изменено, становится недействительным на других серверах. При следующем обращении данные недействительных таблиц читаются непосредственно из базы данных и обновляются в буфере.

← →
Polevi © (2006-10-25 16:11) [56]

>Игорь Шевченко © (25.10.06 16:05) [54]
а иы применим линейную масшатабируемость
колво аппсерверов = колво пользователей системы
красота

← →
Polevi © (2006-10-25 16:14) [57]

>euru © (25.10.06 16:11) [55]
бла бла бла
тоже читали умные книжки
все это конечно очень на бумаге красиво, можно кандидасткую написать
только оправдано ли такое усложнение системы ?

← →
Курдль © (2006-10-25 16:16) [58]

> iZEN © (25.10.06 15:56) [51]

Вот речь не мальчика, но мужа! (с)

Я еще могу добавить сюда несколько капель своего малозаметного опыта.
Там, где использование ХП было очевидно до недавнего времени, их тоже подвинули. Например, при обработке больших массивов данных для создании отчетов, балансов, клирингов, биллингов и т.п. Теперь такие задачи все чаще переносятся из БД в ХД. А все действия над данными производятся специализированными средствами OLAP типа MSTR.
Казалось бы, что интеграция данных из БД (или оперативных источников) - тоже возможное применение ХП. А вот ведь тоже не срослось...
И сюда пришли специализированные программные продукты ETL типа Informatica.

← →
saxon (2006-10-25 16:18) [59]

> ANB © (25.10.06 16:02) [53]

В упомянутых OR-Mapping разработчик может и не иметь дело с SQL.
Как пример:
http://www.devexpress.com - тут они и базу могут создать :)

← →
Вольный Стрелок © (2006-10-25 16:19) [60]

euru © (25.10.06 16:11) [55]

> Могу привести описание, как это сделано в SAP R/3

Нашел тоже систему для подражания...
У них даже контроля целостности на уровне БД нет, внешних и уникальных ключей. Про триггеры и не говорю.
А по "Через фиксированные интервалы времени, обычно 1-2 минуты, запускается механизм синхронизации. " ваще типичный олап

← →
euru © (2006-10-25 16:19) [61]

> Polevi © (25.10.06 16:14) [57]
> только оправдано ли такое усложнение системы ?

А в чём усложнение? И для кого усложнение?

← →
Игорь Шевченко © (2006-10-25 16:23) [62]

saxon (25.10.06 16:18) [59]

> В упомянутых OR-Mapping разработчик может и не иметь дело
> с SQL.
> Как пример:
> http://www.devexpress.com - тут они и базу могут создать
> :)

Это имеется в виду XPO ? Реально это где-то используется ? Какие объемы обрабатываемых данных ? Какое время отклика ?

← →
Игорь Шевченко © (2006-10-25 16:25) [63]

euru © (25.10.06 16:19) [61]

Вот тут было сказано, что процессор и память стали дешевые...Так оно ж лучше на железку, где сервер СУБД крутится, потратить. Сервер приложений тоже не бесплатно достается, верно ? Либо готовый берется и дорабатывается напильником, либо пишется вручную. И то и другое стоит денег, в то время, как процессор с памятью и винчестерами дешевеет...

← →
iZEN © (2006-10-25 16:25) [64]

> Игорь Шевченко © (25.10.06 16:05) [54]
>
> Я конечно извиняюсь, но дешевизну памяти и процессорного
> времени лучше использовать для масштабируемости приложений.

Объектные системы и аппсервера хорошо масштабируются и кластеризуются, в отличие от чисто "функциональных" подходов.

← →
saxon (2006-10-25 16:26) [65]

> Игорь Шевченко © (25.10.06 16:23) [62]

У нас в конторе, парень, программу, для внутренних нужд, пишет при помощи ентого. Пока особо ничего не могу сказать - он только что начал, так кое-какие вещи пока смотрели. (сори)

← →
Игорь Шевченко © (2006-10-25 16:27) [66]

iZEN © (25.10.06 16:25) [64]

> Объектные системы и аппсервера хорошо масштабируются и кластеризуются,
> в отличие от чисто "функциональных" подходов.

С этого места подробнее.

← →
Polevi © (2006-10-25 16:28) [67]

>euru © (25.10.06 16:19) [61]
ну если ты считаешь что реалтзовать описанный тобой алгоритм не сложно в распределенной системе то ноу проблем

← →
euru © (2006-10-25 16:28) [68]

> Вольный Стрелок © (25.10.06 16:19) [60]
> ..У них даже контроля целостности на уровне БД нет, внешних
> и уникальных ключей. Про триггеры и не говорю.

Первичные и внешние ключи, а также индексы всё-таки есть. Контроль целостности тоже имеется. А зачем нужны триггеры, если контроль ведётся на уровне бизнес-логики?

saxon (25.10.06 16:26) [65]

Для внутренних нужд я аж свою собственную систему писал. И эту...как ее...tiopf смотрел. Не впечатлило.

>Игорь Шевченко © (25.10.06 16:27) [66]
ну я понял имеется в виду комната в которой стоит СУБД сервер и Апп сервер
когда начинает тормозить добавляют еще один аппсервер а некий координатор распределяет запросы между ними
и так до [56]

← →
saxon (2006-10-25 16:31) [71]

> Игорь Шевченко © (25.10.06 16:23) [62]

+
Есть там такое - http://www.devexpress.com/Home/Customers.xml
а что конкретно каждый использует - ?

> Игорь Шевченко © (25.10.06 16:29) [69]

Спорить не буду, опыта нет, а паренек - кипятком писает :)

saxon (25.10.06 16:31) [71]

Что такое DevExpress я знаю давно, но у них же - визуальные компоненты. XPO у них совсем недавно появилось, и вряд ли те Customers используют именно его, скорее - компоненты для внешнего вида, благо действительно хорошие.

> Polevi © (25.10.06 16:28) [67]
>ну если ты считаешь что
> реалтзовать описанный тобой алгоритм не сложно в распределенной
> системе то ноу проблем

Этот алгоритм не мной описан, а взят из хелпа SAP. Они его реализовали и эксплуатируют уже не один год и на довольно большом количестве инсталляций. Так что описанный алгоритм - не из области фантастики.

Вот какой итог я хочу подвести.
Лично я умею и люблю писать серверную логику. Знаю, какой красоты иногда получаются результаты, по сравнению с исполнением той же задачи на клиенте.
Но для ускорения процесса производства ПО полезнее все сводить к одной среде, одному языку и общей модели.

>euru © (25.10.06 16:58) [73]
я не говорю что это фантастика
я говорю что реализовать не просто
и стоит подумать стоит ли оно того в разрабатываемой системе
ERP от SAP уже несколько десятков лет разрабатывается, у них было на это время и ресурсы

> ну я понял имеется в виду комната в которой стоит СУБД сервер
> и Апп сервер
> когда начинает тормозить добавляют еще один аппсервер а
> некий координатор распределяет запросы между ними
> и так до [56]

А не проще добавить еще один СУБД сервер ? 10G под это и выпускали. И апп сервер не нужен.

Курдль © (25.10.06 17:01) [74]

> Но для ускорения процесса производства ПО полезнее все сводить
> к одной среде, одному языку и общей модели

Может, лучше разделять усилия разработчиков клиентской и серверной частей ? Например, иметь две группы, каждая сильная в своей области, в результате, ПО должно получиться более производительным (ну или масштабируемым)...

to kaif © (25.10.06 15:49) [48]:
>Потому в интернет всех победил MySQL.
>Вот этот товарисч не умеет никаких ХП выполнять.
Вы это разработчикам MySQL напишите, чтобы выкинули нафиг процедуры, которые они туда недавно таки прикрутили. Расскажите, что зря старались. А то они не в курсе. :)

> субд то разные бывают

Угу. Адабас еще бывает, он тоже умеет распределяться. DB2 - не в курсе, но либо уже умеет, либо скоро научится. Грид нынче моднее 3-х звенки.
Не вижу смысла использовать простенькую СУБД, чтобы фактически самому добавлять ей возможности. Это дороже выйдет.

Какие именно задачи следует решать с помощью ХП? Найти похожие ветки