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

← →
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-страницы организовывать в виде ХП. А вот "обработчик дерева" или "обработчик спектра" не может считаться навешиванием на СУБД лишних вещей, так как это не простое перекладывание работы на сервер СУБД, а расширение возможностей сервера СУБД до уровня, необходимого в данной задаче без замены сервера на более дорогой. То есть ХП следует писать тем, кто намерен сэкономить средства и удешевить продукт.

← →
Danilka © (2006-10-26 15:41) [102]

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

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

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

← →
kaif © (2006-10-26 15:45) [103]

Приведу еще один пример с безопасностью.
Сервер 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 хотят заглянуть в чужие данные в обход всех моих приложений.

← →
kaif © (2006-10-26 15:48) [104]

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

← →
Курдль © (2006-10-26 15:48) [105]

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

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

← →
Курдль © (2006-10-26 15:55) [106]

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

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

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

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

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

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

← →
kaif © (2006-10-26 16:02) [108]

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]
> Да, весьма интересно глянуть на такую "реализацию" - в трехзвенке
> и без применения ХП.

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

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