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

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

В продолжении темы о Web-проектировании выделился вопрос о целесообразности применения ХП. Причем именно в альтернативе с исполнением бизнес-логики на сервере приложений.
Моя позиция - в пользу сервера приложений.
Моя цель - не оспорить чьи-либо утверждения, а в споре прояснить для себя перспективы программирования серверной логики и варианты применения тех или иных методов.

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

> Игорь Шевченко © (25.10.06 10:41) [53]
> Например, минимизация обмена данными между клиентом и сервером,
> снижение нагрузки на сеть - это вроде очевидная задача.
> Разграничение доступа - еще одна.

Всем этим может прекрасно руководить сервер приложений, а не сервер СУБД. Возможно при этом между сервером приложений и сервером БД данных будет "ходить" больше (на несколько процентов, но никак не в разы).

← →
Jeer © (2006-10-25 12:03) [2]

Собственно преимущества трехзвенки более-менее известны и понятны.
Многие отечественные монстры на нее перешли.

Основная мысль - "утончить" клиента и позволить использовать "дохлые" каналы, вся бизнес-логика на appsrv, что позволяет выполнять даже обновление на лету, СУБД выполняет свою рутинную работу.

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

> Jeer © (25.10.06 12:03) [2]
> Основная мысль - "утончить" клиента и позволить использовать
> "дохлые" каналы, вся бизнес-логика на appsrv, что позволяет
> выполнять даже обновление на лету, СУБД выполняет свою рутинную
> работу.

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

← →
saxon (2006-10-25 12:34) [4]

> В продолжении темы о Web-проектировании выделился вопрос
> о целесообразности применения ХП. Причем именно в альтернативе
> с исполнением бизнес-логики на сервере приложений.

И все это - в Web? Врядли это разумно.

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

Курдль © (25.10.06 10:58) [1]

> Всем этим может прекрасно руководить сервер приложений,
> а не сервер СУБД. Возможно при этом между сервером приложений
> и сервером БД данных будет "ходить" больше (на несколько
> процентов, но никак не в разы).

Всем этим может и клиент руководить, не так ли ?

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

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

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

Ты термины "вписывается" и "архитектурная задумка" разъясни, плз.

← →
Курдль © (2006-10-25 12:53) [7]

> Игорь Шевченко © (25.10.06 12:39) [6]
> Ты термины "вписывается" и "архитектурная задумка" разъясни, плз.

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

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

← →
kaif © (2006-10-25 12:58) [8]

Я не понял вопроса.
ХП - это "хранимые процедуры"?
Если так, то ХП - часть арсенала сервера БД, независимо от того, используется трехзвенка или двухзвенка.

Допустим у меня есть накопитель визитов к врачу пациентов с категориям и таких визитов и датами. И я хотел бы построить спектр промежутков (в днях) между визитами. Как я должен поступить? Я могу, конечно, отфетчить всю эту огромную таблицу в какое-нибудь серверное приложение и там разбираться со спектром. Я могу попытаться встать на уши и добиться получения спектра SQL-запросов. Точнее я могу задать вопрос Johnmen-у и, возможно, он придумает как такое сделать - я не справлюсь скорее всего.
А могу поступить проще.
Написать, например, в IB такую процедуру:

CREATE PROCEDURE VISIT_INTERVAL_SPECTRUM(CATEGORY INTEGER)
RETURNS(VISIT_INTEVAL INTEGER)
AS
DECLARE VARIABLE PREVIOUS_DATE DATE;
DECLARE VARIABLE VISIT_DATE DATE;
BEGIN
PREVIOUS_DATE = NULL;

FOR SELECT
VISIT_DATE
FROM
PATIENT_VISIT
WHERE
CATEGORY = :CATEGORY
ORDER BY
VISIT_DATE
INTO :VISIT_DATE
DO
BEGIN
VISIT_INTEVAL = VISIT_DATE - PREVIOUS_DATE;
IF (PREVIOUS_DATE IS NOT NULL) THEN
SUSPEND;
PREVIOUS_DATE = VISIT_DATE;
END
END

После чего я одним SQL-запросом к этой ХП получу спектр для категории 13:

SELECT
VISIT_INTEVAL, COUNT(*)
FROM
VISIT_INTERVAL_SPECTRUM(13)
GROUP BY VISIT_INTEVAL

Мне кажется, что это - очевидная задача для сервера БД, а не длля сервера приложений или двузвенного клиента.
Таким образом для ХП есть применение, независимо от того, двузвенка используется или трехзвенка.

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

Курдль © (25.10.06 12:53) [7]

> Так вот, чаще всего работа с данными ограничивается уровнем
> технических служб и предполагает максимально упрощенную
> модель записи/хранения/выборки.

Это просто в разработке, но непроизводительно и немасштабируемо.

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

> kaif © (25.10.06 12:58) [8]
> Я могу попытаться встать на уши и добиться получения спектра SQL-запросов.

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

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

Курдль © (25.10.06 13:04) [10]

> Именно так и надо сделать. В большинстве случаев создание
> ХП продиктовано нежеланием возиться с запросом.

Это ты так от потенциальных конкурентов избавляешься ? :)

← →
Курдль © (2006-10-25 13:06) [12]

> Игорь Шевченко © (25.10.06 13:02) [9]
> Это просто в разработке, но непроизводительно и немасштабируемо.

Я подустал от недопонимания. Что есть "непроизводительно"?
Какие действия производятся и над каким объемом данных, когда начинаются проблемы с производительностью?

← →
saxon (2006-10-25 13:06) [13]

> В большинстве случаев создание ХП продиктовано нежеланием
> возиться с запросом.

Странно, всегда думал в точности до наоборот. :)

← →
kaif © (2006-10-25 13:08) [14]

Более того.
Я могу немного развить эту ХП в дальнейшем, сделав так, чтобы она возвращала поля CATEGORY, VISIT_INTERVAL для всех категорий, если в нее передается параметр NULL.
И написать еще одну ХП для запрооса всех спектров разом, которая вызовет ту ХП.
А следом написать еще одну ХП, которая вызовет ХП, запрашивающую готовые спектры и возвращающую значение
MAX(VISIT_INTERVAL) , MIN(VISIT_INTERVAL), AVG(VISIT_INTERVAL)
с группировкой по категориям.

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

Хотя, впрочем, все это так легко именно в IB благодаря такой вещи как SUSPEND и возможности обращаться с наборами, возмращаемыми ХП как с простыми таблицами.

Не знаю, как с другими серверами. Возможно, в MS SQL это придется все реализовывать на курсорах... Но даже там имеет смысл ограничиться хотя бы первой ХП. которую я описал. Так как реляционная модель не позволяет в лоб получать спектр промежутков значений упорядоченного множества. А такого рода задачи часто возникают.

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

Курдль © (25.10.06 13:06) [12]

> Я подустал от недопонимания. Что есть "непроизводительно"?
>
> Какие действия производятся и над каким объемом данных,
> когда начинаются проблемы с производительностью?

А тебе Ашот в [8] пример привел...

← →
kaif © (2006-10-25 13:10) [16]

Курдль © (25.10.06 13:04) [10]
Именно так и надо сделать. В большинстве случаев создание ХП продиктовано нежеланием возиться с запросом.

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

← →
Desdechado © (2006-10-25 13:10) [17]

Имхо, каждая часть многозвенки должна заниматься своим делом.
1. СУБД - рулить данными, правами, целостностью, хранением, доступом.
2. Сервер приложений - ковырять бизнес-логику.
3. Клиент - принимать решения и вводить/получать результаты.

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

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

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

> Desdechado © (25.10.06 13:10) [17]

Готов подписаться под каждым словом!

← →
kaif © (2006-10-25 13:26) [19]

2 Курдль ©

Ну так как насчет SQL-запроса спектра промежутков дат визитов?
Слабо?
Тогда не надо и делать общих заявлений относительно возможностей SQL. ХП позволяют сделать некоторую работу серверу СУБД за пределами реляционных ограничений. В IB для этого используют SUSPEND, а в MSSQL - курсоры или временные таблицы. И это все задачи, которые невозможно или крайне сложно (медленно) решать с помощью QL-запросов.

← →
kaif © (2006-10-25 13:28) [20]

Еще один типичный пример такой задачи - устранить "дырки в нумерации".
Кто напишет мне SQL-запрос, реализующий столь сомнительную в логическом отношении задачу?

← →
stone © (2006-10-25 13:37) [21]

> kaif © (25.10.06 13:28) [20]
> Еще один типичный пример такой задачи - устранить "дырки
> в нумерации".
> Кто напишет мне SQL-запрос, реализующий столь сомнительную
> в логическом отношении задачу?

на TSQL

есть таблица (ID int, Value varchar(50)) ID соответственно с "дырками"

select identity(int,1,1) as ID, Value into #tmp from Table delete from Table insert into table select * from #tmp drop table #tmp

← →
Bless © (2006-10-25 13:45) [22]

> kaif © (25.10.06 13:28) [20]
>
> Еще один типичный пример такой задачи - устранить "дырки
> в нумерации".
> Кто напишет мне SQL-запрос, реализующий столь сомнительную
> в логическом отношении задачу?

На MS SQL.
Дырявое поле - t1.kod (не identity)
declare @x int
set @x=0
update t1 set @x=kod=@x+1

← →
Bless © (2006-10-25 13:48) [23]

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

← →
Курдль © (2006-10-25 14:00) [24]

> kaif © (25.10.06 13:26) [19]
> Ну так как насчет SQL-запроса спектра промежутков дат визитов?
> Слабо?

Меня "на слабо" не так-то просто поймать :)
Давай субмодель данных и подробное описание, что за "спектр" надо получить. На досуге гляну.

← →
Ученик чародея © (2006-10-25 14:29) [25]

>
> Курдль © (25.10.06 10:57)
>
> В продолжении темы о Web-проектировании выделился вопрос
> о целесообразности применения ХП. Причем именно в альтернативе
> с исполнением бизнес-логики на сервере приложений.
> Моя позиция - в пользу сервера приложений.
> Моя цель - не оспорить чьи-либо утверждения, а в споре прояснить
> для себя перспективы программирования серверной логики и
> варианты применения тех или иных методов.

Производительность и гибкость не есть критерий для заказчика. Основным критерием для заказчика является простота установки, поддержки и работы с приложением того же клиента БД.

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

← →
euru © (2006-10-25 14:29) [26]

> Desdechado © (25.10.06 13:10) [17]
> Имхо, каждая часть многозвенки должна заниматься своим делом.
> 1. СУБД - рулить данными, правами, целостностью, хранением, доступом.
> 2. Сервер приложений - ковырять бизнес-логику.
> 3. Клиент - принимать решения и вводить/получать результаты.
>
> Но утверждают, что масштабировать сервер приложений легче, чем СУБД. > И дешевле. Здесь не знаю, не сталкивался.

Руление правами и доступом надобно бы тоже перенести в бизнес-логику, потому что правила их применения могут быть привязаны не только к объектам БД, но и к бизнес-объектам.

В СУБД не должно быть прикладных ХП. Их функционал должен реализовываться на уровне сервера приложений.

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

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

euru © (25.10.06 14:29) [26]

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

Я надеюсь, у тебя есть чем подтвердить столь смелое утверждение ?

← →
kaif © (2006-10-25 14:33) [28]

Курдль © (25.10.06 14:00) [24]
Давай субмодель данных и подробное описание, что за "спектр" надо получить. На досуге гляну.

Я такие мудреные слова не понимаю. Я - скромный писатель хранимых процедур.

Имеется таблица, в которой лежат даты визитов пациентов.

PATIENT_ID VISIT_DATE
===================
1 01.01.2006
1 05.01.2006
1 09.01.2006
1 19.01.2006
....
2 06.03.2006
2 08.03.2006
2 11.03.2006
2 14.03.2006
....
....

Допустим даже, что имеется еще одна таблица, в которолй каждый пациент имеет категорию:

PATIENT_ID CATEGORY_ID
====================
1 1
2 1
3 2
4 3
.....

Требуется написать один SQL-запрос без всяких временных таблиц, ХП и т.п., который вернет такой спектр (промежуток в днях между двумя визитами подряд и число таких промежутков):

VISIT_INTERVAL COUNT
=====================
2 1 (имеется 1 промежуток в 2 дня между визитами)
3 2 (имеется 2 промежутка в 3 дня между визитами)
4 2 (имеется 2 промежутка в 4 дня между визитами)
10 1 (один раз врачи сидели без дела 10 дней)
...

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

Усложнение - сгруппировать это все по категориям и ответить одним SQL-вопросом на такой вопрос:
Каков минимальный промежуток между визитами каждой категории, максимальный и средний интервал. Или что-то подорбное.

Я показал, что подобные задачи легко решаются с помощью ХП в интербейзе. Одной ХП и запроса с группировкой к ней достаточно, чтобы получить простой спектр промежутков. Вторая ХП может запросить первую и получить все впектры по категориям. Третья ХП может выдать на гора минимум, максимум и среднее по каждой категории. Все это очень легко написать и еще проще отладить. И займет эта работа не более 15 минут, даже если ошибиться в каждом операторе по одному разу. В результате получм гарантированно правильные результаты и быстро работающий код, который возвращает все что нужно одним SQL-запросом.

Я могу посидеть месяц, поговорить с Johnmen-ом, Zacho, загрузить тебя и Desdechado, Petr.V.Abramov-а с его ORACLE и так далее.
И если бы мне платили повременный оклад, то я бы, возможно, этим и занялся для поднятия своей крутизны в собственных глазах.

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

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

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

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

Мой ответ - ДА. Я ТАК БЫ И СДЕЛАЛ.
Если бы писал трехзвенку.

Но Я ПОКА НЕ СОШЕЛ С УМА:
1. Писать трехзвенки, когда двухзвенок почему-то оказывается всегда достаточно.
2. Пренебрегать богатейшими возможностями определенного сервера и вместо этого реализовывать руками в приложении (пускай серверном!) то, что сервер уже и так умеет делать.
3. Платить за функционал сервера, который заведомо не хочу использовать.

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

Хорошо сказано, поддерживаю на все 100%!

А чему, собственно, удивляться, когда в книжках, объясняющих, "как надо правильно программировать", черным по белому написано, например, вот так:

protected Object getObjectFromStorage (OID oid)
{
String key = oid.ToString();
dbRec = SQL execution result of:
"Select * from PROD_SPEC where key=" + key;

ProductSpecification ps = new ProductSpecification();
ps.setOID(oid);
ps.setPrice( dbRec.getColumn("PRICE"));
ps.setItemID(dbRec.getColumn("ITEM_ID");
ps.setDescrip(dbRec.getColumn("DESC"));

return ps;
}

Крэг Ларман, "Применение UML и шаблонов проектирования", стр. 535

> А разгрузить его можно перенеся работу по обработки данных на

другое узкое место :)

> Игорь Шевченко © (25.10.06 14:31) [27]
> Я надеюсь, у тебя есть чем подтвердить столь смелое утверждение ?
Вообще-то в выделенном тобой тексте целых три утверждения. :)

1. Сервер БД - это узкое место.
Разве это неверное утверждение? Увеличение количества активных клиентов, введение дополнительных бизнес-систем приведёт к увеличению нагрузки на сервер. Что, в свою очередь, приведёт к снижению его производительности, а значит, и к снижению производительности прикладного ПО.

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

euru © (25.10.06 15:17) [36]

> 2. Поэтому чем больше его разгрузить, тем эффективнее он
> будет работать. А разгрузить его можно перенеся работу по
> обработки данных на сервер приложений.

И сделать другое узкое место, об чем неоднократно в этой ветке говорится.

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

> kaif © (25.10.06 14:42) [30]
> 1. Писать трехзвенки, когда двухзвенок почему-то оказывается
> всегда достаточно.

Где и кому их "всегда достаточно"?
Распределенные системы писать приходилось?

> 2. Пренебрегать богатейшими возможностями определенного
> сервера и вместо этого реализовывать руками в приложении
> (пускай серверном!) то, что сервер уже и так умеет делать.

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

> 3. Платить за функционал сервера, который заведомо не хочу
> использовать.

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

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

при этом полагается, что сервер приложений -- это такая волшебная штучка, которая сама по себе нагрузки не испытывает.

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

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

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

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

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

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

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

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