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

← →
Курдль © (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 и так далее.
И если бы мне платили повременный оклад, то я бы, возможно, этим и занялся для поднятия своей крутизны в собственных глазах.

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

← →
ANB © (2006-10-25 14:41) [29]

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

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

← →
kaif © (2006-10-25 14:42) [30]

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

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

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

← →
Danilka © (2006-10-25 14:45) [31]

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

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

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

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

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

← →
DiamondShark © (2006-10-25 15:04) [33]

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

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

← →
ANB © (2006-10-25 15:07) [34]

> kaif © (25.10.06 14:42) [30]

+1

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

ANB © (25.10.06 15:07) [34]

НУ НЕТУ НА ЭТОМ САЙТЕ СИСТЕМЫ РЕЙТИНГОВ!!!

← →
euru © (2006-10-25 15:17) [36]

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

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

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

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

euru © (25.10.06 15:17) [36]

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

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

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

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

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

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

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

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

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

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

← →
DiamondShark © (2006-10-25 15:21) [39]

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

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

← →
Игорь Шевченко © (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]
> ..У них даже контроля целостности на уровне БД нет, внешних
> и уникальных ключей. Про триггеры и не говорю.

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

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

saxon (25.10.06 16:26) [65]

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

← →
Polevi © (2006-10-25 16:30) [70]

>Игорь Шевченко © (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]

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

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

saxon (25.10.06 16:31) [71]

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

← →
euru © (2006-10-25 16:58) [73]

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

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

← →
Курдль © (2006-10-25 17:01) [74]

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

← →
Polevi © (2006-10-25 17:01) [75]

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

← →
ANB © (2006-10-25 17:03) [76]

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

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

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

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

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

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

← →
Polevi © (2006-10-25 17:10) [78]

>ANB © (25.10.06 17:03) [76]
ну это в случае оракл
субд то разные бывают

← →
vuk © (2006-10-25 17:27) [79]

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

← →
ANB © (2006-10-25 17:35) [80]

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

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

← →
Курдль © (2006-10-25 21:52) [81]

> kaif © (25.10.06 14:33) [28]

Либо я недостаточно внимательно вник в суть проблемы, либо:
with ALIAS_1 as (select V1.VISIT_DATE - (select max(V2.VISIT_DATE) from VISITES V2 where V2.VISIT_DATE < V1.VISIT_DATE) as VISIT_INTERVAL from VISITES V1) select distinct count(*) from ALIAS_1 group by VISIT_INTERVAL

Согласен, что этот запрос будет работать дольше, чем ХП, но если на прогнозируемом объеме данных этот запрос покажет приемлемые результаты...

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

Дошел таки я до Кайта:

"Зависимость от базы данных должна быть целью, к котрой нужно стремиться, а не избегать ее. Если руководство предприятия считает возможным вкладывать в базу данных денежные средства и хочет, чтобы программное обеспечение разрабатывалось за минимально короткое время, то единственный путь - это использовать все возможности базы данных.
Дело в том, что если не считать самых простых приложений, независимость от базы данных - удовольствие чрезвычайно дорогое и поглощающее огромное количество ресурсов.
...
В действительности, бОльшая часть программного обеспечения создана именно для работы со стандартной корпоративной базой данных. Представляется сомнительной в подобных обстоятельствах необходимость в независимости от базы данных. Создать приложение быстро и всего лишь с помощью нескольких строчек кода - это то, к чему необходимо стремиться. А работа с условием независимости от базы данных или, что еще хуже, пренебрежение (преднамеренное или как результат недостаточных знаний) возможностями базы данных не должно быть целью"
Лучшим способом, позволяющим достичь некотрого уровня мобильности приложения для множества баз данных, является кодирование всех компонентов базы данных, используемых приложением, в хранимых процедурах. В связи с этим возникает вопрос: если кодирование производится в хранимых процедурах, а каждый производитель имеет свой собстенный язык, не возникнет ли зависимость от производителя?
И да, и нет. Видимые компоненты приложения в безопасности. Логика приложения (существующая вместе с логикой данных) тоже в безопасности. Логика данных кодируется в процессе работы с базой данных. Так как все это скрыто в хранимой процедуре, пользуясь (на самом деле это всегда нужно использовать) расширенными средствами каждого производителя, можно получить данные более высокого уровня.
Если приложение разработано и внедрено, то оно навсегда остается внедренным в базу данных. Если приложение перемещается в другую базу данных, то его необходимо адаптировать, обновив с помощью новых возможностей и функций. Просто так его перенести не получится."

(с) Том Кайт

← →
Petr V.Abramov (2006-10-25 23:34) [83]

1. с т.з производительности
не надо гонять огромные объемы данных с DB-сервера на app-сервер. Это, правда, решается гигагарцами и гигабайтами.
2. С т.з. философии. лучше 2 уровня (DB, клиент), чем 3. но это решается изменением философии
3. Все аргументы тута звучали как "на трехзвенке можно сделать то же, и не сложнее". И не было ни одного, где написано "это проще" (пусть меня, фигово чиатющего, поправят). молотки.ру не считаем

← →
Ketmar © (2006-10-26 01:02) [84]

>[82] Игорь Шевченко(c) 25-Oct-2006, 23:00
>В действительности, бОльшая часть программного обеспечения
>создана именно для работы со стандартной корпоративной
>базой данных.
это неполная цитата или я чего-то совсем не понял?

← →
euru © (2006-10-26 01:50) [85]

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

> Дошел таки я до Кайта:
Рассуждения Кайта характерны для команды разработчиков на таком предприятии. Все доводы - это фактически завуалированные оправдания в необходимости их присутствия на предприятии.
Компании, разрабатывающие прикладное ПО, в большинстве случаев стремяться как раз к обратному: охватить своими разработками как можно больше платформ и СУБД. При этом они стараются минимизировать код, зависящий от СУБД, чтобы уменьшить вероятность возникновения ошибок при адаптации.

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

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

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

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

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

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

← →
euru © (2006-10-26 02:46) [86]

> Petr V.Abramov (25.10.06 23:34) [83]

> 1. с т.з производительности не надо гонять огромные объемы
> данных с DB-сервера на app-сервер. Это, правда, решается
> гигагарцами и гигабайтами.
Я, возможно, сейчас буду похож на Этуша из "Ивана Васильевича...", но всё-таки...
У нас в компании одна СУБД. На ней одновременно работают 3 основных системы: система разработки, система тестирования и продуктивная система. Плюс ещё периодически создаются 1-2 "песочницы" для оотработки и тестирования некоторых глобальных решений. В свою очередь, с продуктивной системой одновременно работают 5 заводов. Каждый завод работает с такими компонентами как Финансы, Логистика, Контроллинг, Учёт персонала. Неужели вы думаете, что реализация всей бизнес-логики на уровне СУБД будет более производительным, нежели вынесением её на сервера приложений? Я также не понимаю проблемы "перегонки огромных данных". Ведь между сервером БД и серверами приложений используются гигабитные каналы.

> 2. С т.з. философии. лучше 2 уровня
> (DB, клиент), чем 3. но это решается изменением философии
Если 2 уровня, то бизнес-логику придётся размазывать как на серверную сторону, так и на клиентскую, что в дальнейшем может привести к проблемам. Если 3 уровня, то вся бизнес-логика концентрируется на уровне сервера приложений, тем самым оставляя степень свободы как в выборе системы хранения данных, так и в выборе системы взаимодействия с пользователем.

> 3. Все аргументы тута звучали как "на трехзвенке можно сделать
> то же, и не сложнее". И не было ни одного, где написано
> "это проще" (пусть меня, фигово чиатющего, поправят). молотки.
> ру не считаем
А если количество звеньев понизить? Получим "на двухзвенке можно сделать то же, что и на однозвенке, и не сложнее", но также никто не напишет, что "это будет проще". Естественно, реализация трёхзвенки сложнее. Но при этом появляются дополнительные возможности. Например, в двухзвенке контроль ввода информации осуществляется клиентской стороной. И если вдруг понадобится переделать интерфейс пользователя (например, через веб-браузер), то придётся переписывать и этот контроль. В трёхзвенке же как обработку данных, так и контроль введённой информации производит сервер приложений. На дисплее пользователя отображается только сформированный сервером приложения экран для ввода данных. Поэтому перенос интерфейса в веб-браузер никаким образом не затронет контроль введённых пользователем значений.

← →
Sergey Masloff (2006-10-26 06:22) [87]

euru © (26.10.06 01:50) [85]
>А возможно ли, например, с помощью ХП получение данных из каких-либо >внешних источников данных и, наоборот, выгрузка обработанных данных во >внешние источники данных?
Да, возможна. Более того, делается и несложно ;-)

>Ведь между сервером БД и серверами приложений используются гигабитные каналы.
И что? Ваш сервер приложений делает join быстрее СУБД? А система ввода-вывода сервера успевает эти гигабитные каналы наполнять? А если их больше станет?

>Если 2 уровня, то бизнес-логику придётся размазывать как на серверную >сторону, так и на клиентскую, что в дальнейшем может привести к >проблемам
Как говорила моя бабушка, сдуру можно и . сломать. Можно ж на сервере ее сосредоточить - мы ж про ХП. На фиг на клиенте своя логика?

>И если вдруг понадобится переделать интерфейс пользователя (например, >через веб-браузер), то придётся переписывать и этот контроль
Как раз не придется. Он на сервере ж? Я не теоретически говорю - у нас есть и веб интерфейс и через веб-сервисы и еще несколько вариантов.

← →
Sergey13 © (2006-10-26 08:37) [88]

> [85] euru © (26.10.06 01:50)
> Рассуждения Кайта характерны для команды разработчиков на
> таком предприятии. Все доводы - это фактически завуалированные
> оправдания в необходимости их присутствия на предприятии.
> Компании, разрабатывающие прикладное ПО, в большинстве случаев
> стремяться как раз к обратному: охватить своими разработками
> как можно больше платформ и СУБД. При этом они стараются
> минимизировать код, зависящий от СУБД, чтобы уменьшить вероятность
> возникновения ошибок при адаптации.

Странно, что ЭТО пишет человек, который 10 постами выше писал про SAP R/3. 8-))))))))))))

← →
Danilka © (2006-10-26 09:15) [89]

[81] Курдль © (25.10.06 21:52)
Причем тут MSSQL2005? Давай на Анси пример приведи, раз уж такая пьянка пошла по поводу унификации и независимости от СУБД.
:))

[85] euru © (26.10.06 01:50)
> Ну, и как с помощью ХП создать окно для ввода данных

Зачем вырывать гланды через задний проход?
Впрочем, при желании, даже это возможно. :) (я не про гланды, а про вопрос) :)

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

Один страшный тайн раскажу: Кайт пижет книги только про Орокол и ни про какие другие СУБД.
:)

[86] euru © (26.10.06 02:46)
> Если 2 уровня, то бизнес-логику придётся размазывать как
> на серверную сторону, так и на клиентскую

Почему???

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

У кого и почему???

← →
Petr V.Abramov (2006-10-26 09:52) [90]

> Ведь между сервером БД и серверами приложений используются
> гигабитные каналы.
а на фига вообще эти каналы-то???
польза м.б. только в одном случае - Pidarox в качестве СУБД, с вытекающими отсюда средствами разработки "серверной" логики
> Неужели вы думаете, что реализация всей бизнес-логики на уровне СУБД
> будет более производительным, нежели вынесением её на сервера
> приложений
думаю, да.
select ...
from a,b
where a.id=b.id
быстрее сделает сервер, чем кодеры на сервере приложений

← →
Игорь Шевченко © (2006-10-26 10:09) [91]

euru © (26.10.06 01:50) [85]

> Компании, разрабатывающие прикладное ПО, в большинстве случаев
> стремяться как раз к обратному: охватить своими разработками
> как можно больше платформ и СУБД. При этом они стараются
> минимизировать код, зависящий от СУБД, чтобы уменьшить вероятность
> возникновения ошибок при адаптации.

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

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

А какие есть альтернативы ?

> Вообще-то есть путь ещё короче: использование уже готовых
> решений. Стороннее ПО, уже разработанное для решения задач,
> аналогичных задачам предприятия, в общем случае эффективнее
> и дешевле разработок, сделанных умельцами на предприятии.
>

Эффективнее - может быть. Дешевле - очень под вопросом.
Я тебе один вещь скажу - ПО, ориентированное на конкретную СУБД может быть разработано не только "умельцами на предприятии", но еще и сторонним независимым разработчиком.

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

Как ты понимаешь, разрабатывающая ПО компания себе в убыток работать не собирается. А если собирается, то заниматься она этим будет недолго.

> Ну, и как с помощью ХП создать окно для ввода данных, а
> также организовать их вывод?

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

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

Обычно головой думают до принятия решений.

← →
saxon (2006-10-26 10:52) [92]

> euru © (26.10.06 01:50) [85]
> Компании, разрабатывающие прикладное ПО, в большинстве случаев
> стремяться как раз к обратному: охватить своими разработками
> как можно больше платформ и СУБД. При этом они стараются
> минимизировать код, зависящий от СУБД, чтобы уменьшить вероятность
> возникновения ошибок при адаптации.

Приходилось и мне делать такое, но не понятно - чем тут ХП не угодило?

← →
euru © (2006-10-26 11:49) [93]

> Sergey Masloff (26.10.06 06:22) [87]

> Да, возможна. Более того, делается и несложно ;-)
Т.е. предлагается на СУБД, которая и так уже загружена по своему прямому предназначению, повесить ещё задачи, ей несвойственные (напр., взаимодействие с другими системами, расчёт 3-мерной модели и т.д.)? И это будет наиболее эффективным решением?

>И что? Ваш сервер приложений делает join
> быстрее СУБД? А система ввода-вывода сервера успевает эти
> гигабитные каналы наполнять? А если их больше станет?
Всё-таки бизнес-логика - это несколько больше, чем последовательность SQL-операторов, разреженных арифметическими инструкциями. Поэтому JOIN таблиц по отношению к бизнес-логики - это такая же элементарная задача, как команда процессора ADD по отношению к оператору "+" языка высокого уровня. Не стоит эмулировать объединение таблиц на сервере приложений, если с этим эффективно справляется СУБД.

> Как говорила моя бабушка, сдуру можно и . сломать.
> Можно ж на сервере ее сосредоточить - мы ж про ХП. На фиг
> на клиенте своя логика?
Бизнес-логика - это не только обработка информации и контроль её целостности. Это ещё и ввод данных в систему, и вывод результатов. Каким образом, не написав ни одной строки на клиентской стороне, ХП будут взаимодействовать с клиентом, чтобы гарантировать корректность введённых данных? Опять же, как ХП процедуры будут управлять отображением результатов на клиенте?

> Как раз не придется.Он на сервере ж? Я не теоретически говорю - у нас есть
> и веб интерфейс и через веб-сервисы и еще несколько вариантов.
Т.е., написав интерфейс пользователя на WinAPI, вы, не переписывая ни одной строки клиентской стороны, можете обратиться к системе через веб-браузер и получить в нём точно такой же интерфейс?

> Sergey13 © (26.10.06 08:37) [88]
> Странно, что ЭТО пишет человек, который 10 постами выше писал про SAP R/3. 8-))))))))))))
А в чём противоречия между написанным здесь и 10-ю постами выше?

> Игорь Шевченко © (26.10.06 10:09) [91]

> Я много лет живу на свете, добрую половину из них занимаюсь
> программированием, связанным с базами данных. Поверь, на
> своем веку я не сталкивался с типичностью задачи адаптации
> приложения под разные СУБД. Я бы не сказал, что мой мир
> настолько ограничен, что только его узостью обуславливается
> отсутствие массовых прецедентов адаптации приложений.
А как же 1С, SAP R/3, Axapta?

> Если ты задаешь такие вопросы, то либо ты не в теме, либо
> просто хочется пофлудить.
Не в теме чего? Может ли ХП организовать визуальный интерфейс ввода-вывода? Здесь я, действительно, не в теме. Знаю только, что возможности ХП в 98-м году этого не позволяли.
Можно ли на серверной стороне управлять интерфейсом пользователя? Можно. Именно так и делается в SAP R/3. Сервер приложения формирует экран и отсылает его на компьютер пользователя. Задача клиента сводится к отображению полученного экрана на монитор и отправке введённой информации обратно на сервер приложения.

← →
euru © (2006-10-26 11:59) [94]

> Игорь Шевченко © (26.10.06 10:09) [91]

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

> saxon (26.10.06 10:52) [92]

> Приходилось и мне делать такое, но не понятно - чем тут
> ХП не угодило?
1. У разных производителей СУБД синтаксис ХП отличается, а у некоторых СУБД вообще может не быть ХП.
2. Логика, заложенная в ХП, может быть настолько сложна, что, вместо того чтобы заниматься обработкой запросов, сервер БД будет тратить свои ресурсы на обработку этих ХП.

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

euru © (26.10.06 11:49) [93]

> А как же 1С, SAP R/3, Axapta?

SAP R/3 написали по сути свою базу данных. У них много времени и средств, не думаю, что у кого-то из присутствующих в данной ветке аналогичное положение.
У 1С кстати тоже много времени и средств.

> Бизнес-логика - это не только обработка информации и контроль
> её целостности. Это ещё и ввод данных в систему, и вывод
> результатов.

Ввод данных в систему - это не бизнес-логика.

> Каким образом, не написав ни одной строки на клиентской
> стороне, ХП будут взаимодействовать с клиентом, чтобы гарантировать
> корректность введённых данных? Опять же, как ХП процедуры
> будут управлять отображением результатов на клиенте?

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

> Можно ли на серверной стороне управлять интерфейсом пользователя?
> Можно. Именно так и делается в SAP R/3. Сервер приложения
> формирует экран и отсылает его на компьютер пользователя.
> Задача клиента сводится к отображению полученного экрана
> на монитор и отправке введённой информации обратно на сервер
> приложения.

А кроме SAP R/3 кто-нибудь так делает ?

← →
stone © (2006-10-26 12:22) [96]

> Ввод данных в систему - это не бизнес-логика.

Ты бизнес-логику с бизнес-процессом не путаешь?

> Каким образом, не написав ни одной строки на клиентской
> стороне, ХП будут взаимодействовать с клиентом, чтобы
> гарантировать
> корректность введённых данных? Опять же, как ХП процедуры
> будут управлять отображением результатов на клиенте?
>
> Никаким образом. Точно так же, как таблица в базе данных
> не управляет вводом данных и выводом результатов.

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

← →
saxon (2006-10-26 12:47) [97]

> euru © (26.10.06 11:59) [94]
> 1. У разных производителей СУБД синтаксис ХП отличается

Синтаксис тут абсолютно ни при чем, главное чтоб интерфес был одинаков.

А что касаеться, > а у некоторых СУБД вообще может не быть ХП.
врядли стоит рассматривать такие варианты, за их изначальной (вариантов)непрактичности. Ну на самом деле, надо ли делать систему, которая может работать с ораклом или парадоксом?

> euru © (26.10.06 11:59) [94]
> 2. Логика, заложенная в ХП, может быть настолько сложна,
> что, вместо того чтобы заниматься обработкой запросов,
> сервер БД будет тратить свои ресурсы на обработку этих ХП.

Ну про то где и какое узкое место тут уже много говорили.

← →
Игорь Шевченко © (2006-10-26 12:53) [98]

euru © (26.10.06 11:59) [94]

> Про адаптацию не мои слова, а Кайта. Я их просто прокомментировал.
> Наверно, он, прежде чем говорить, головой подумал. А если
> не думал, то стоит ли серьёзно относиться к его другим высказываниям?
>

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

Вот этого Кайт не писал. Потому мои слова про думание головой относятся именно к твоему комментарию.

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

Бред какой-то. Если какие-то действия нужны для бизнес-процесса, они так или иначе должны быть выполнены. Поэтому фраза "вместо того, чтобы заниматься обработкой запросов" - бредовая изначально.

← →
Evgeny V © (2006-10-26 14:23) [99]

> euru © (26.10.06 11:59) [94]
> 2. Логика, заложенная в ХП, может быть настолько сложна,
> что, вместо того чтобы заниматься обработкой запросов,
> сервер БД будет тратить свои ресурсы на обработку этих ХП.
>

для примера допустим сложныйз апрос из таблицы с кучей JOIN в СУБД IB6, рассмотрим упрощенно

SELECT * FROM TABLE1 WHERE ..... запрос выполняется 20 сек

SELECT * FROM MYXP(PARAM1,PARAM2...) выполняется 2 сек

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

← →
Danilka © (2006-10-26 14:30) [100]

[93] euru © (26.10.06 11:49)
> Каким образом, не написав ни одной строки на клиентской
> стороне, ХП будут взаимодействовать с клиентом, чтобы гарантировать
> корректность введённых данных? Опять же, как ХП процедуры
> будут управлять отображением результатов на клиенте?

Если данные, переданые ХП не корректные, то райзеррор с соответствующим сообщением, которое клиент добросовестно показывает. Без всяких трехзвенок.

← →
kaif © (2006-10-26 15:24) [101]

2 Курдль © (25.10.06 21:52) [81]

Я заценил Ваш запрос.
:)

Это синтаксис ORACLE. Вряд ли конструкцию with Поймет MySQL. Насчет MSSQL не знаю - может и поймет, я с ним давно не работал.

А IB уж точно не поймет.

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

В общем-то благодаря именно таким развитым возможностям синтаксиса ORACLE (запросы над результатами других запросов) позволили мне вообще обойтись без ХП в моей последней работе с ORACLE.

Если Вы работаете в основном с ORACLE, то я понимаю, что идея использования ХП Вам может показаться излишней, особенно если ORACLE не имеет команды SUSPEND и невозможно с процедурами обращаться так, как в IB (делать к ним запросы, как к таблицам).

Но как ни крути, дело ведь здесь философски не в ХП.

А в том, позволительно ли разработчикам юзать особенный арсенал средств сервера?

Допустим, кто-то работает с деревьями.
Вы будете настаивать на том, что и здесь совсем не обязательны ХП.
Имея в виду, что ORACLE имеет синтаксис, посвященный таким нереляционным вещам, как дерево. Но ведь это только ORACLE.

А остальные сервера?

Если кто-то в IB посредством ХП расширяет "синтаксис сервера" до возможностей ORACLE, то что в этом дурного?
Например, я могу в IB сделать в процедуре рекурсивный вызов, если мне нужно обработать "деревянную структуру" вида ID, PARENTY_ID. И при этом я продолжаю юзать бесплатный FB.

Я же не могу предлагать своим клиентам (малым фирмам) ни покупать ORACLE, ни тем более юзать пиратский, если они хотят уложиться в приемлемый бюджет.

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

И для ряда задач 90% эта функциональности избыточны.

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

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

Всякий раз, встраивая ХП, разработчик должен просто ответить себе на вопрос: "А как именно я сейчас расширяю сервер СУБД? Что такого я добавляю, что было бы достаточно универсальным?" Здесь подход такой же как при создании новых классов. "Не делайте метаклассом то, что Вам не нравится" (автора не помню, но фраза хорошая).

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

[101] kaif © (26.10.06 15:24)
Вообще-то это не Орокол, а MSSQL2005.
Именно начиная с версии 2005 появилась конструкция "WITH ...", так называемое "общее табличное выражение".

> Я же не могу предлагать своим клиентам (малым фирмам) ни
> покупать ORACLE, ни тем более юзать пиратский, если они
> хотят уложиться в приемлемый бюджет.

OracleXE, также как и MSSQL2005XE бесплатные для любого, в т.ч. и коммерческого использования.
Ограничения - 4 ГБ база и какой-бы ни был навороченый сервер использоваться будет не более 1 ГБ оперативки и 1 процессор.

Приведу еще один пример с безопасностью.
Сервер IB (не знаю, как ORACLE) не позволяет делать GRANT на строку таблицы.
Если я хочу иметь на уровне запроса SELECT управление правами доступа на уровне строки, то самый простой путь - использование ХП.

ID, DATA, USER_NAME
=================
1 1231 VASIA
2 456546 VASIA
3 77897 PETIA

Допустим данные DATA чрезвычайно секретны. Настоолько секретны, что я не могу дать никаких GRANT на таблицу в целом пользователю VASIA. И у меня нет трехзвенки, которая вуалировала бы эту проблему.

Так вот я пишу процедуру:

CREATE PROCEDURE GET_SECRET_DATA
RETURNS(ID INTEGER, DATA INTEGER)
AS
BEGIN
FOR SELECT FROM SECRET_DATA
WHERE USER_NAME = :USER /*USER - это функция, возвращающая в IB имя текущего пользователя*/
INTO :ID, :DATA
DO SUSPEND;
END

И делаю:

GRANT SELECT ON TABLE SECRET_DATA TO PROCEDURE GET_SECRET_DATA;
GRANT EXECUTE ON PROCEDURE GET_SECRET_DATA TO VASIA;
GRANT EXECUTE ON PROCEDURE GET_SECRET_DATA TO PETIA;

И имею полную гарантию безопасности данных, даже если VAISA или PETIA - злостные хакеры и кроме моего приложения умеют запускать какой-нибудь IBExpert и с помощью утилит типа ISQL хотят заглянуть в чужие данные в обход всех моих приложений.

После чего VASIA может работать с GET_SECRET_DATA как с обычной таблицей
SELECT * FROM GET_SECRET_DATA
и даже не подозревать, что там еще хранятся недоступные для него данные.

> Danilka © (26.10.06 15:41) [102]
> Вообще-то это не Орокол, а MSSQL2005.

Вообще-то именно этот запрос создан и испробован первым делом на "Sybase ASA". Но без каких либо изменений он обязан отработать и на DB2 и на оракле :)

> kaif © (26.10.06 15:45) [103]
> Приведу еще один пример с безопасностью.
> Сервер IB (не знаю, как ORACLE) не позволяет делать GRANT
> на строку таблицы.
> Если я хочу иметь на уровне запроса SELECT управление правами
> доступа на уровне строки, то самый простой путь - использование
> ХП.

Опять готов поспорить! Самый простой путь - использование представлений! :)
И уверяю, что в наше время целесообразность управления доступом через привилегии для каждого пользователя сомнительна!

Курдль © (26.10.06 15:55) [106]

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

А в нынешнем сезоне чем модно управлять доступом ? :)

Danilka © (26.10.06 15:41) [102]
OracleXE, также как и MSSQL2005XE бесплатные для любого, в т.ч. и коммерческого использования.

Спасибо. Я не знал. Это действительно очень ценная для меня информация. Отстал от жизни... Я знал, что есть Oracle и MSSQL бесплатный для разработчиков, но для коммерческого использования - слышу впервые.

> Игорь Шевченко © (26.10.06 15:57) [107]
> А в нынешнем сезоне чем модно управлять доступом ? :)

Как "чем"?!! Я уж в нескольких ветках настаиваю, что рулит сервер приложений! :)

Но ведь и кроме смеха, это недалеко от истины.

> Курдль © (26.10.06 16:04) [109]

> Но ведь и кроме смеха, это недалеко от истины.

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

Курдль © (26.10.06 16:04) [109]

Call me paranoid, но я никогда не стану доверять управление доступом к данным кому-либо кроме сервера базы данных.

> Evgeny V © (26.10.06 16:10) [110]
> Не всегда, задачи разного уровня бывают. И в любом случае
> сервер приложений не отменяет необходимость в ХП, когда
> они действительно нужны.

Это достойная эпитафия на всей это безусловно полезной, но затянувшейся ветке!!! :)

> Игорь Шевченко © (26.10.06 16:10) [111]
> Call me paranoid, но я никогда не стану доверять управление
> доступом к данным кому-либо кроме сервера базы данных.

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

Курдль © (26.10.06 16:15) [112]

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

Курдль © (26.10.06 15:55) [106]
Опять готов поспорить! Самый простой путь - использование представлений! :)

С этим трудно не согласиться. Снимаю аргумент.

> Игорь Шевченко © (26.10.06 16:16) [113]
> Ну вот приходит такой вот пользователь к серверу со своим
> средством доступа ...

Это что за кекс? Враг народа? Любовница сисадмина, завербованная ЦРУ? :)
Ведь предполагается, что сервер приложений не доверяется кому попало. Да и на оракле, например, без dbo или owner-a даже не узнаешь, какие таблицы есть в конкретной БД (разве что ты и вправду шпиён и имеешь модель БД).

Курдль © (26.10.06 16:22) [115]

> Ведь предполагается, что сервер приложений не доверяется
> кому попало. Да и на оракле, например, без dbo или owner-
> a даже не узнаешь, какие таблицы есть в конкретной БД (разве
> что ты и вправду шпиён и имеешь модель БД).

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

> Игорь Шевченко © (26.10.06 16:33) [116]
> Я вот одного не совсем понимаю - зачем нагружать сервер
> приложений задачами, которые присущи (и успешно реализованы
> там) серверу базы данных.
> Пусть он занимается своим делом - обслуживает тонких клиентов.

Во что выльется, например, реализация бизнесс-процесса регистрации пользователя системы от уровня пользовательского интерфейса до получения им соответствующих привилегий?

← →
saxon (2006-10-26 17:01) [118]

> Во что выльется, например, реализация бизнесс-процесса регистрации
> пользователя системы от уровня пользовательского интерфейса
> до получения им соответствующих привилегий?

Да, весьма интересно глянуть на такую "реализацию" - в трехзвенке и без применения ХП.

Курдль © (26.10.06 16:44) [117]

> Во что выльется, например, реализация бизнесс-процесса регистрации
> пользователя системы от уровня пользовательского интерфейса
> до получения им соответствующих привилегий?

В создание сессии ? Я угадал ? А привилегии у него будут проверяться при попытках доступа к соответствующим объектам базы данных.

> saxon (26.10.06 17:01) [118]
> Да, весьма интересно глянуть на такую "реализацию" - в трехзвенке
> и без применения ХП.

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

Курдль © (26.10.06 16:44) [117]
Во что выльется, например, реализация бизнесс-процесса регистрации пользователя системы от уровня пользовательского интерфейса до получения им соответствующих привилегий?

Ничего страшного.
Я как раз пару дней назад решал подобную проблему.
Я создал таблицу:

TABLE ACTION_LIST:
ID, NAME
=================
1 Доступ к тому-то
2 Право редактировать то-то
3 Доступ к интерфейсу такому-то
4 Доступность кнопки такой-то
....
Достаточно неформальный и на понятном людям языке списочек вещей, существенных для конкретной задачи, которую я решал.

У меня есть еще таблица

TABLE ACTION_PRIVILEGES:
ACTION_ID, PRIVILEGE, RELATION_NAME
================
1 S TABLE1
1 I TABLE1
1 U TABLE1
1 S TABLE2
2 I TABLE2
2 E PROCEDURE1
...

и так далее.
Разумеется, привилении на какие-то объекты могут "пересекаться" в разных "привилегиях на функции системы".

Ничего страшного.
Далее я написал именно ХП, которая возвращает мне все нужные команды GRANT или REVOKE, если администратор предоставляет/отзывает функцию системы для данного пользователя:

/*Процедура возвращает команды, которые необходио выполнить для предоставления всех прав пользователю в связи с действием ACTION_ID*/ CREATE PROCEDURE GET_PRIVILEGE_COMMANDS(USER_ID INTEGER, ACTION_ID INTEGER, SET_GRANTS SMALLINT) RETURNS (GRANT_COMMAND VARCHAR(255) CHARACTER SET ASCII) AS DECLARE VARIABLE USER_NAME VARCHAR(31) CHARACTER SET ASCII; DECLARE VARIABLE RELATION_NAME VARCHAR(31) CHARACTER SET ASCII; DECLARE VARIABLE PRIVILEGE CHAR(1) CHARACTER SET ASCII; DECLARE VARIABLE TMP VARCHAR(30) CHARACTER SET ASCII; BEGIN SELECT USER_NAME FROM USER_LIST WHERE USER_ID = :USER_ID INTO :USER_NAME; /*Все привилегии на объекты базы, которые надо предоставить*/ FOR SELECT DISTINCT AP.PRIVILEGE, AP.RELATION_NAME FROM ACTION_PRIVILEGES AP LEFT OUTER JOIN RDB$USER_PRIVILEGES UP ON RDB$USER = :USER_NAME AND RDB$RELATION_NAME = AP.RELATION_NAME AND AP.PRIVILEGE = UP.RDB$PRIVILEGE AND AP.RELATION_NAME = UP.RDB$RELATION_NAME WHERE :SET_GRANTS = 1 AND ACTION_ID = :ACTION_ID AND UP.RDB$PRIVILEGE IS NULL UNION /*Все привилегии на объекты базы, которые надо отозвать*/ SELECT DISTINCT AP1.PRIVILEGE, AP1.RELATION_NAME FROM ACTION_PRIVILEGES AP1 INNER JOIN RDB$USER_PRIVILEGES UP ON RDB$USER = :USER_NAME AND RDB$RELATION_NAME = AP1.RELATION_NAME AND AP1.PRIVILEGE = UP.RDB$PRIVILEGE AND AP1.RELATION_NAME = UP.RDB$RELATION_NAME LEFT OUTER JOIN ACTION_PRIVILEGES AP2 ON AP1.RELATION_NAME = AP2.RELATION_NAME AND AP1.PRIVILEGE = AP2.PRIVILEGE AND AP2.ACTION_ID <> :ACTION_ID WHERE :SET_GRANTS = 0 AND AP1.ACTION_ID = :ACTION_ID AND AP2.PRIVILEGE IS NULL INTO :PRIVILEGE, :RELATION_NAME DO BEGIN IF (PRIVILEGE = "S") THEN TMP = "SELECT ON "; ELSE IF (PRIVILEGE = "I") THEN TMP = "INSERT ON "; ELSE IF (PRIVILEGE = "U") THEN TMP = "UPDATE ON "; ELSE IF (PRIVILEGE = "D") THEN TMP = "DELETE ON "; ELSE IF (PRIVILEGE = "R") THEN TMP = "REFERENCES ON "; ELSE IF (PRIVILEGE = "E") THEN TMP = "EXECUTE ON PROCEDURE "; IF (SET_GRANTS = 1) THEN GRANT_COMMAND = "GRANT "||TMP||RELATION_NAME||" TO "||USER_NAME||";"; ELSE GRANT_COMMAND = "REVOKE "||TMP||RELATION_NAME||" FROM "||USER_NAME||";"; SUSPEND; END END

Дарю этот текст широкой публике.
:)
Работает изумительно.

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

TABLE USER_ACTIONS
USER_ID, ACTION_ID
==================
1 1
1 2
2 1
3 1
3 2
3 3
....

И таблица, в которой перечислены все юзеры
TABLE USER_LIST
ID USER_NAME NAME
==================
1 VASIA Вася
2 PETIA Петя
....

Итого мы имеем 4 таблицы: таблица юзеров, таблица "функций системы" , таблица привилегий функций на объекты базы и таблица привилегий юзеров на "функции системы".

Это - вся система безопасности того, что я сейчас пишу.

При старте приложение запрашивает из таблицы USER_ACTIONS все привилегии юзера на функции системы и обработчики событий OnShow всех дельфийских форм проверяют привилегии на нужные функции вызовом функции IsActionGranted(action_id: integer). Пользователь получает тот интерфейс, который должен получить по замыслу разработчика и согласно тем правам на функции, которые ему предоставил "Администратор", поставив птичку рядом с "функцией системы", когда раздавал привилегии этому юзеру.

Когда Администратор "ставит птичку" у функции № 13, тут же вставляется запись в таблицу USER_ACTIONS и тут же делается запрос к той ХП, что я привел.

SELECT * FROM GET_PRIVILEGE_COMMANDS(1, 13, 1)
Процедура возвращает набор фраз вида GRANT...., которые просто исполняются утилитой администратора.

Если администратор снял птичку - соответствующая запись удаляется из таблицы USER_ACTIONS и тут же делается запрос к той же процедуре

SELECT * FROM GET_PRIVILEGE_COMMANDS(1, 13, 0)

(последний парамет теперь 0)

И тут же выполняются команды REVOKE..., которая эта процедура вернула.
------------------------

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

Дальше мне остается запустить приложение администратора и раздать птички юзерам.

Я не утверждаю, что нельзя сделать такие же вещи без той ХП, что я написал. Можно. Но невозможно будет этот код вот так вот легко выставить на форуме и порекомендовать всем, кто работает с IB. И к тому же в ХП удобнее было это реализовать, чем на стороне клиента. Не знаю, почему удобнее. Просто удобнее - и все тут.

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

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

Зато ХП вполне могут отменить необходимость в сервере приложений.

Давайте посчитаем.

Имеем довольно сложную задачу.

Нужен клиент (сделаем его более менее толстым, чтобы не терять гибкости)
и нужна централизованная логика.

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

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

В варианте а) нам апп.сервер не нужен. Большая часть тривиальных ошибок ловится уже при компиляции хранимок. При изменении структуры БД мы сразу видим места, которые из-за этого поломались. Мы можен вносить изменения в логику кусочками, опять таки контролируя, что при этом сломали.

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

> Но для этого административному модулю системы приходилось
> давать действительно опасные привилегии доступа к системным
> таблицам и представлениям, причем включая модификацию.

Эта - а зачем ?
ЗЫ. Все уже сделано. До нас. (С) Операция Ы.

2 ANB © (26.10.06 17:18) [122]
Добавлю и свои 5 копеек.
Если я исполдьзую ХП в IB, то мне сервен не даст в случае изменения структуры таблиц совершить целый ряд ошибок, если эти таблицы обвешаны ХП, так как IB поддерживает целостность метаданных. Например я не смогу так вот запросто удалить использующееся в какой-то ХП поле. А если это поле используется в каком-то там серверном приложении, я на стадии удаления поля просто могу об этом ничего не знать.

> ANB © (26.10.06 17:18) [122]

Мы начали ходить по кругу. Пройдись по ветке, где я рассматривал преимущества ООП, архитектурного анализа и т.п. перед процедурным программированием.

> ANB © (26.10.06 17:20) [123]
> Эта - а зачем ?

Что "зачем"? "Зачем сдавать заказчику систему с полным функционалом, если можно обучить фельдшера провинциальной поликлиники управлять вводом пользователем и распределением их привилегий средствами оракла?"

> Курдль © (26.10.06 17:25) [125]

Зачем давать привелегии на модификацию системных таблиц ?

Есть куча отработанных готовых решений. Которые можно просто вставить к себе в проект. Будет не сложнее, чем на трехслойке.

> где я рассматривал преимущества ООП

Нету у него никаких преимуществ. А для особо желающих оракл дает возможность работать с явой и объектами на pl/sql. Опять таки апп.сервер ни на фиг не сдался.

ИМХО : Частенько попытки все сделать через ООП приводят к более громоздкому и сложному решению. Все хорошо в меру и к месту.

Курдль © (26.10.06 17:25) [125]

> "Зачем сдавать заказчику систему с полным функционалом,
> если можно обучить фельдшера провинциальной поликлиники
> управлять вводом пользователем и распределением их привилегий
> средствами оракла?"

Как бы предусматривается, что у оракла есть администратор. Ведь все равно, какие-то задачи администрирования фельдшеру придется решать, раздача прав - это не единственные действия по администрированию.

Расскажу один случай. Может быть это тоже поможет разобраться.
Как-то меня пригласили на одну фирму, как человека, "знающего Интербейс". У них была тяжелая проблема - их складская программа каким-то образом (возможно из-за ошибки в самой программе или в данных) создала неверные складские остатки и они не могли отгружать некоторые виды товара из-за жесткого ограничения "минус на складе".
База данных была сложная и огромная.
Приложение я вообще не мог изменить (EXE-файл).
Но мне повезло в одном отношении.
Я посмотрел список хранимых процедур (а там их было три тысячи !!!) и нашел там процедуру, буквально по-английски названную "заново сформировать складские остатки", которая была чисто технической и вызвалась из каких-то других процедур. Взглянув на текст этой процедуры, я пришел к выводу, что накопители данных она не затрагивает (приходы и расходы) а лишь делает какие-то "перетряхивания" дальше.
Я запустил ее и сервер думал пару минут, после чего "все исправилось".

Как бы я смог решить эту проблему, будь это все организовано в приложении? Вот так вот - за 5 минут?

> ANB © (26.10.06 17:30) [126]
> > где я рассматривал преимущества ООП
> Нету у него никаких преимуществ.

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

Поэтому на твое заявление совершенно спокойно тебе отвечаю: "ООП дает многократное преимущество в скорости IT разработок!".

← →
saxon (2006-10-26 17:38) [130]

> Курдль © (26.10.06 17:14) [120]
> И как тебе это показать?

Я, Вас, не просил мне что то показывать. Читайте внимательнее.

> Игорь Шевченко © (26.10.06 17:31) [127]
> Как бы предусматривается, что у оракла есть администратор.

Кем предусматривается? Я привел пример из жизни.
Согласно контракту БД типа "оракл" не требовала администрирования. И после внедрения так все и осталось. Наша фирма осуществляла поддержку системы несколько лет, за которые пару раз приходилось восстанавливать
данные из бэкапленного дампа после падения аппаратных средств. Потом
заказчик отказался от наших услуг (все и так прекрасно работало).

Курдль © (26.10.06 17:45) [131]

Примеры из жизни разные бывают. Бывает пример с раздачей прав пользователем при установке системы. Тоже из жизни.
В твоем примере кто дампы делал ?

> saxon (26.10.06 17:38) [130]
> Я, Вас, не просил мне что то показывать. Читайте внимательнее.

Насколько внимательнее читать? Вот читаю по буквам:

> saxon (26.10.06 17:01) [118] > Да, весьма интересно глянуть на такую "реализацию" - в трехзвенке > и без применения ХП.

Этот Ваш пост был чисто риторическим, а последующий должен был повлечь конфронтацию?

> Поэтому на твое заявление совершенно спокойно тебе отвечаю:
> "ООП дает многократное преимущество в скорости IT разработок!
> ".

Я уже писал, что для поклонников ООП оракл предусмотрел объектные типы.

> Игорь Шевченко © (26.10.06 17:47) [132]
> В твоем примере кто дампы делал ?

Дампы делали джобы (не к столу будет сказано) :)
Но! Во время внедрения системы с этим справлялся далекостоящий от IT персонал (посылали нам дампы мылом, чтобы мы могли разобраться с проблемами в данных).

> ANB © (26.10.06 17:50) [134]
> Я уже писал, что для поклонников ООП оракл предусмотрел
> объектные типы.

Объектные типы != ООП. Когда оракл предоставит возможность вести проекты от бизнес-логики до пользовательского интерфейса (Оракл Формз не предлагать!) ...

Дамп ORACLE мылом - круто.
Все вопросы снимаются.
Если Ваши заказчики могут посылать мылом гигабайты, то у них достаточно аппаратных мощностей, чтобы вообще все на Visual Basic перевсти и вместо сервера БД использовать текстовый файл.
:)

Кстати, а нафиг сервер-то?
У меня есть знакомый, который писал Web-сайты на PHP+MySQL, но в результате "развития" пришел к тому что пишет все исключительно на C + текстовый файл и уверяет, что любой сервер БД - от лукавого. От неумения программистов писать код. Это напоминает мне Вашу позицию: "ХП от неумения писать SQL-запросы". В идеале вообще не должно быть никакого сервера БД. Кто сказал, что он вообще нужен? Ведь насколько проще сделать так, чтобы каждый объект в ООП сам себя куда-нибудь записывал бы, например, в отдельный файл. Вото кто сказал, что "Товар на складе" вообще нужно совать в СУБД? Давайте сделаем метод SaveToFile и покончим с этим. А если кто-то хочет посмотреть остатки на складе, пускай вызывает метод GoodsCollection.LoadFromExisitingFiles() И длальше отыскивает там товар методом GoodsCollection.GetGood: TGood, после чего смотрит свойство Good.StockRemainder.

Зачем СУБД?

Объясните.
Я не вижу смысла в СУБД. Она только замедляет выборку всех товаров в кэш, так как грузит страницы файла база данных, где кроме товаров еще и другие вещи записаны.

> (Оракл Формз не предлагать!)

Ну тогда оракл аппликейшион :)

Я видел и парочку самостоятельных разработок. Одна из них вообще в веб-интерфейсе работала.

А первая - полутонкий клиент на делфи + ядро на оракле. Стояла по всем наложкам татарстана. Проработала лет 10. До сих пор в наложках ее с ностальгией вспоминают. Впрочем наследники этой системы до сих пор используются в реализации серьезных проектов.

Курдль © (26.10.06 17:51) [135]

Точно так же далекостоящий от IT персонал мог выполнить хранимую процедуру, создающую пользователя и дающую ему все необходимые привилегии :))

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

← →
ИА (2006-10-27 06:52) [143]

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

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

Рецеп банкета "Трехзвенка" от ИА

Бульон

Взять 1 базу данных и тщательно очистить ее от триггеров. Добавить структуры данных в виде таблиц, первичные и вторичные ключи, cascade правила, required поля и прочие железные принципы которые можно задать в виде индексов и механизмов самих таблиц. Равномерно взбить. Отсортировать хранимые процедуры - те что меняют данные помыть от лишней бизнес логики и связать в пучки, по одному на порцию транзакции. Из тех что данные запрашивают отобрать посвежее, остальное выкинуть. Взять права пользователя на таблицы, обвязать ниточкой и положить в скрипт, привязав другой конец к администратору.
Залить все это данными и поставить на сильную загрузку. Когда жесткие диски на сервере диски размягчеют, загрузку поменять на минимальную и долить результаты Index Analyzer. Загрузку убрать, букет прав вытащить.

Второе

На второе взять свежую с кровью вырезку из современных технологий сервера приложений, если вы взяли .NET то можно использовать и так, если Java то придется замочить вырезку в маринаде на некоторое время (маринад готовиться из смеси JBOSS и Tomcat в равной пропорции), если все что вы смогли достать это Delphi то отбейте ее дополнительно золотым молоточком.
Подготовленную вырезку порезать на отдельные методы, положить на сервер, щедро посыпав бизнес логикой, и прижать сверху грузом из прав доступа. Следите что бы кусочки не касались друг друга. Подождать некоторое время что бы вышел сок проектных спецификаций. Попробовать его на вкус и досыпать отчетов если специй недостаточно.

Гарнир

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

Подача

Клиента аккуратно разложить по сети. Выложить горкой бизнеслогику, в центре сделать углубление в которое аккуратно налить данные (для этого возьмите OleDB и лейте данные по ней тонкой струйкой).
Следите что бы данные не просочились к гарниру.
Поставить мисочки с плагинами для сервера.

Приятного аппетита

[105] Курдль © (26.10.06 15:48)
Действительно, работает, спасибо. А я думал, это чисто Микросовтская выдумка. :))
Правда, твой запрос все равно неправильный. Вместо "distinct count(*)" надо "VISIT_INTERVAL, count(*)". :))

Не знаю, что-то мне кажется, что проблема частично в используемой СУБД. Многие из перечисленых здесь вопросов решаются специальными средствами Oracle (аналитические функции, row level security, ...). Гибкая реализация хранимых процедур в IB [FB] также посволяет это релизовать своими руками (пусть с некоторым падением производительности). А вот простого решения для MS SQL (2005 не пробовал) я не нахожу (может недостаточно опыта), поэтому просто необходим сервер, который бы мог помочь решить эти проблемы :)

> Согласен, что этот запрос будет работать дольше, чем ХП,
> но если на прогнозируемом объеме данных этот запрос покажет
> приемлемые результаты...

И получится история про маляра Шлейхема.

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