Flying Dutchman wrote:
> C>Нормальные языки имеют нааамного больше средств для борьбы со
> сложностью, чем языки хранимых процедур (возможность юнит-тестирования,
> ООП всякое и т.п.)
> Зато языки хранимых процедур обладают большими возможностями для работы
> с реляционными данными.
Работа с реляционными данными в большинстве случаев сводится к "сделать
запрос". Это прекрасно можно сделать без хранимых процедур. А тут еще и
LINQ подкатывает, который сведет на нет большую часть "преимуществ" БД.

Ну и я не говорю про ORM.

> Это преимущество перевешивает их недостатки (например, отсутствие ООП).
Не перевешивает в большинстве случаев.

> Юнит-тестирование для баз данных существует. Для Oracle есть пакет
> utPLSQL, для
> тестирования хранимых процедур SQL Server я использую NUnit и пишу
> тестовые программы на C#.
И как мне использовать моки, например?

> Можно хранить хранимые процедуры в текстовом файле, а текстовый файл в SVN.
Угу. Пробовали. В одном файле их хранить нельзя — пойдут сплошные
конфликты. А разбивать на файлы не так-то просто.

> P>>По меньшей мере странно обрабатывать данные в реляционным хранилище
> языком, не предназначенном для этого.
> C>По меньшей мере странно использовать *хранилище* для обработки данных.
> База данных — это не просто хранилище данных, а хранилище данных +
> хранилище бизнес-правил + устройство обработки данных.
Нет. База данных — это именно хранилище, на которое многие пытаются
навернуть того, что там не должно быть.

Flying Dutchman wrote:
> C>По моему опыту, перенос сложной логики в БД — путь к монструозным
> По моему опыту — наоборот. Чтобы не быть голословным, приведу примеры
> некоторых проектов, в которых я принимал участие.
Мой опыт работы с приложениями:
1. База данных для автоматизации предприятия — около 1500 таблиц на
Oracle, интегрируем с нашей системой. Жуть. Рефакторингу не поддается
из-за того, что нет нормальных инструментов и огромного объемы.

2. У соседей — сравнительно небольшой проект. Сначала такой же крутой
DBA заставлял все делать в хранимых процедурах на MSSQL. В результате
поимели кучу проблем с версированием. В итоге люди выбросили это все
нафиг и стали использовать NHibernate.

3. Мой текущий проект — первая версия была написана в лучше оракловом
стиле, с row level security, странными политиками безопасности и
непонятными хранимыми процедурами для workflow и бизнес-правил.
Переписали на Hibernate + трехзвенка, для бизнес-правил взяли drools,
для workflow — JBoss jBPM. Сейчас бизнес-консултанты добавляют в неделю
по десятку правил для разных клиентов.

Нет, я видел успешные проекты на Oracle — в котором люди работали над
кодом через Remote Desktop, так как других вариантов просто не было. Но
я бы такой проект писать не стал.

> C>Ага. И при использовании такого подхода — получить мучения с системами
> C>контроля версий, совместной работой и т.п.
> И какие же проблемы могут быть с системами контроля версий ? Если поступать
> правильно, то есть хранить хранимые процедуры в файле, а файл в системе
> контроля версий, то никаких проблем не будет. Если же создавать и
> редактировать хранимые процедуры прямо на сервере — то да, будут проблемы.
Про один файл я уже сказал.

> C>Я уж не говорю про крайнюю убогость языка по сравнению даже с обычным C#.
> Ну, не убогость, а ограниченность для процедурных задач. Но этот недостаток
> с лихвой компенсируется удобством использования SQL для работы с данными.
> И то эта ограниченность свойственна, например, Transact SQL, а PL-SQL
> уже полнофункциональный язык программирования.
Он нифига не полнофункциональный. Он на уровне 80-х годов, там нет
современных фич.

> C>А это вообще приводит к бреду.
> К чему приводит ??? Описанная практика это вообще best practice в
> мире Oracle (за подробностями отсылаю к статьям Люкаса Йеллема
В best practices меня можно не тыкать — я их уже много видел.

А отделение работы с данными от логики для организации псевдо-DAL'а
приводить только к бессмысленному увеличению объема работы.

> Ну, в общем-то, да. Работая в Oracle, вполне можно этого добиться для
> многих проектов.
> Да и у SQL Server 2005 есть много возможностей. Можно, например, писать
> хранимые процедуры на C#.
Я работал с приложениями, построеными на Oracle. В большинстве случаев
это монстры, которые живут годами, добавляя заплатки из-за того, что
невозможно сделать нормальный рефакторинг.

Здравствуйте, Mika Soukhov, Вы писали:

MS>Бизнес-правила — это: послать уведомление о подтверждении заказа; сделать скидку X если сумма превысила Y; удалить товар, если заказ не подтвердился в течении времени Z.

MS>Foreign Key, Primary Key, Constraints — это системный уровень. К бизнесу он никакого отношения не имеет (если, конечно, у вас бизнес не построен на создании СУБД).

Это широко распространенное заблуждение.

Подробно вопрос о бизнес-правилах обсуждается, например, в книге
Дейта What Not Khow. The Business Rules Approach to Application Development

На странице 12 читаем:

...note that the PRIMARY KEY and FOREIGN KEY clauses correspond to business rules...

(...отметим, что предложения PRIMARY KEY и FOREIGN KEY относятся к бизнес-правилам...)

или немного ранее

Indeed, foreign key constraints in particular are an important case of
business rules in general.

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

Так что ограничение целостности являются бизнес-правилами.

Здравствуйте, Cyberax, Вы писали:

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

А какие проблемы с юнит-тестированием серверного кода? И, простите, зачем мне ООП в реляционной СУБД?! Свят, свят, свят...

C>Покажи мне как нормально положить хранимые процедуры в SVN?

Гм... Для хранения исполнимого кода используем VSS. На раз интегрируется хоть с Management Studio, хоть с MultiEdit. Я предпочитаю последний. Модель в ервине и в том же самом VSS.

C>Кроме того, очень часто девелоперам приходится работать на одном сервере (так как поставить себе на личные компьютеры полную базу данных часто нереально).

Т.е. разделение на Production, Test & Development Environment придумали лохи?

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

Даешь каждому разработчику по серверу.

C>По меньшей мере странно использовать хранилище для обработки данных.

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

Здравствуйте, Cyberax, Вы писали:

P>>Гм... Выносить вкуда? На апп.сервер? Который в конце концов сгенерит инструкцию типа
C>Именно.



C>А если потребуется перед измененим сальдо сначала направить счета на подтверждение к координинатору?

И в чем проблема?! Вы не знаете как это реализовать без апп.сервера?

C>А письмо как формировать будем? Конкатенацией строк? А я могу мой любимый Velocity использовать в качестве темплейтного движка? А может MVEL? А как насчет использования LDAP для взятия почтового адреса пользователя?

Опять наружу вылазит незнание возможностей используемой СУБД. М.б. стоит чуть больше уделить внимания их изучению? Дабы не изобретать велосипед в виде апп. сервера

C>Ты будешь лепить интерфейсы к базе?

Что то я не помню, чтоб мы с Вами выпивали на брудершафт?!

C>Нет. Эта функциональность для _нормальных_ приложений обязательна. Люди очень плохо реагируют на ошибки типа "Constraint filed_cannot_be_null violation. Transaction rolled back".

Гм... Интересно где в приведенных мной отрывках Вы увидели возможность получения клиентом такого сообщения?

C>А у меня это все описано вот примерно так:
C>

C>class Something
C>{
C>    @Validate(notNull=true, messageKey="account.cant.be.null")
C>    void setAccount(Account account);
C>}
C>

C>"account.cant.be.null" — это локализуемый ресурс, будет определен примерно так: "ru.account.cant.be.null=Не указан счет получателя для ${that.name}!".

И что будет, если доступ к базе будет получен не через Ваш апп сервер?

C>Да, и при этом система байндинга автоматически будет подкрашивать поле красным цветом при ошибке, дизэйблить кнопку 'OK' и т.п.

Тот же фунционал реализуется и без "системы байндинга" как два пальца об асфальт.

Здравствуйте, Flying Dutchman, Вы писали:

FD>Здравствуйте, Cyberax, Вы писали:

C>>Flying Dutchman wrote:
>>> C>В SQL — работа с данными. Логику в хранимых процедурах поддерживать
>>> сложно и неудобно.
>>> Почему же "сложно и неудобно" ? По опыту своих проектов могу сказать, что
>>> большую часть логики удобно реализовать в хранимых процедурах,
>>> тем более что логика
C>>По моему опыту, перенос сложной логики в БД — путь к монструозным проектам.

FD>По моему опыту — наоборот. Чтобы не быть голословным, приведу примеры
FD>некоторых проектов, в которых я принимал участие.

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

No business logic in database:

No store procedures
Only very simple triggers

Move CPU-intensive work to applications:

Joins
Sorting
...

Здравствуйте, _Oleg_, Вы писали:

_O_>Но вот наткнулся на описание
_O_>Архитектуры eBay.
_O_>Судя по всему, реализовав логику на БД, они бы столкнулись с проблемой производительности.

_O_>

_O_>No business logic in database:
_O_>

_O_>No store procedures
_O_>Only very simple triggers
_O_>

_O_>Move CPU-intensive work to applications:
_O_>

_O_>Joins
_O_>Sorting
_O_>...
_O_>

Зачот. Однозначно. Они на уровне applications гараздо лучше сделают Joins, Sorting ..., чем СУБД, которые именно для этого предназначены. Долго ржал...

Здравствуйте, pkarklin, Вы писали:

_O_>>Move CPU-intensive work to applications:
_O_>>

_O_>>Joins
_O_>>Sorting
_O_>>...
_O_>>

_O_>>[/q]

P>Зачот. Однозначно. Они на уровне applications гараздо лучше сделают Joins, Sorting ..., чем СУБД, которые именно для этого предназначены. Долго ржал...

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

Здравствуйте, Flying Dutchman, Вы писали:

MS>>Бизнес-правила — это: послать уведомление о подтверждении заказа; сделать скидку X если сумма превысила Y; удалить товар, если заказ не подтвердился в течении времени Z.

MS>>Foreign Key, Primary Key, Constraints — это системный уровень. К бизнесу он никакого отношения не имеет (если, конечно, у вас бизнес не построен на создании СУБД).

FD>Это широко распространенное заблуждение.

Тоесть, таких неграмотных как я много? Ну чтож, скучать не будем.

FD>На странице 12 читаем:

FD>

FD>...note that the PRIMARY KEY and FOREIGN KEY clauses correspond to business rules...

FD>(...отметим, что предложения PRIMARY KEY и FOREIGN KEY относятся к бизнес-правилам...)

Любой автоматизированные бизнес в мире (выращивание бананов и продажа оружейного плутония) объединяют как минимум три бизнес-правила

pkarklin wrote:
..., чем СУБД, которые именно для этого предназначены.
> Долго ржал...
Зря смеешься. Это именно так.

Зачастую просто написать тупой императивный код, чем громоздить запросы
и работать с курсорами.

У меня примерно та же ситуация — клиенты один раз загружают с сервера
нужные данные (которые при этом чаще всего еще и во внутрипроцессном
кэше лежат), а потом уже работают с ними на локальных узлах. Так как
иначе сервер БД бы просто умер.

Flying Dutchman wrote:
> Indeed, foreign key constraints in particular are an important case of
> *business rules* in general.
> (В самом деле, ограничение по внешнему ключу является частным случаем
> *бизнес-правила*.)
> Так что ограничение целостности являются бизнес-правилами.
Достаточно редко объекты в БД соответствуют 1-в-1 реальным
бизнес-объектам. Так что FKC — это один из _способов_ задавать
бизнес-правила, но не самый мощный.

pkarklin wrote:
> C>Нормальные языки имеют нааамного больше средств для борьбы со
> сложностью, чем языки хранимых процедур (возможность юнит-тестирования,
> ООП всякое и т.п.)
> А какие проблемы с юнит-тестированием серверного кода? И, простите,
> зачем мне ООП в реляционной СУБД?! Свят, свят, свят...
Ну или там ФП. Или логическое программирование для правил. Ну как-бы то,
что люди начали повсеместно использовать 20 лет назад.

> C>Покажи мне как нормально положить хранимые процедуры в SVN?
> Гм... Для хранения исполнимого кода используем VSS. На раз интегрируется
> хоть с Management Studio, хоть с MultiEdit. Я предпочитаю последний.
> Модель в ервине и в том же самом VSS.
А вот мы VSS не используем (и не будем). Нам что делать? Провайдеров SCC
API для SVN нормальных нет.

> C>Кроме того, очень часто девелоперам приходится работать на одном
> сервере (так как поставить себе на личные компьютеры полную базу данных
> часто нереально).
> Т.е. разделение на Production, Test & Development Environment придумали
> лохи?
Естественно, разработчики будут работать не на production'е. Суть в том,
что они скорее всего будут работать все на _одном_ сервере.

> C>В случае, когда логика от базы отделена — часто можно использовать
> центральную базу, к которой будут цепляться серверы на личных компьютерах.
> Даешь каждому разработчику по серверу.
Можно. Но дорого и неудобно — еще и проблемы с синхронизацией появятся.

> C>По меньшей мере странно использовать *хранилище* для обработки данных.
> Окститесь! Современные СУБД это не просто хранилише!!! Это целый
> конгломерат функциональности, причем реляционный движок значимая, но не
> самая большая часть.
Вот. И эта остальная часть — по большей части сливает нормальным
системам разработки. Так как она не была изначально для этого предназначена.

Здравствуйте, Cyberax, Вы писали:

Поскипано...

>> Окститесь! Современные СУБД это не просто хранилише!!! Это целый
>> конгломерат функциональности, причем реляционный движок значимая, но не
>> самая большая часть.
C>Вот. И эта остальная часть — по большей части сливает нормальным
C>системам разработки. Так как она не была изначально для этого предназначена.

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

Здравствуйте, Cyberax, Вы писали:

C>..., чем СУБД, которые именно для этого предназначены.
>> Долго ржал...
C>Зря смеешься. Это именно так.


Не надо рассказывать мне сказки, чтоб самописные джоины и сортировки "сделали" их аналоги на промышленных серверах СУБД!

C>Зачастую просто написать тупой императивный код, чем громоздить запросы
C>и работать с курсорами.

Курсоры идут в сад! А вот "запросы" — это то, что умеет "переваривать" СУБД гараздо лучше, чем самопальный императивный код на апп. сервере.

C>У меня примерно та же ситуация — клиенты один раз загружают с сервера
C>нужные данные (которые при этом чаще всего еще и во внутрипроцессном
C>кэше лежат), а потом уже работают с ними на локальных узлах. Так как
C>иначе сервер БД бы просто умер.

Даешь всю базу на клиента! Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...

Здравствуйте, pkarklin, Вы писали:

P>Здравствуйте, Cyberax, Вы писали:

C>>У меня примерно та же ситуация — клиенты один раз загружают с сервера
C>>нужные данные (которые при этом чаще всего еще и во внутрипроцессном
C>>кэше лежат), а потом уже работают с ними на локальных узлах. Так как
C>>иначе сервер БД бы просто умер.

P>Даешь всю базу на клиента! Возвращение к истокам? Все работают с локальными копиями. Еще один спец по разгрузке серверов баз данных от их непосредственных обязанностей...

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

Здравствуйте, _Oleg_, Вы писали:

_O_>Нагрузка на базу существенно ниже, если сортировку производить на сервере приложений либо на клиенте.

Господи Всемилостевший... Взываю к тебе...

Господа, но вы сами себя послушайте, а...

Если ОДИН сервер СУБД не справляется с нагрузкой от большого числа пользователей, то мы между ним и пользователями поставим ЕЩЕ ОДИН СЕРВЕР, который решит эти проблемы? Бред...

_O_>На сколько я знаю, при сортировке Oracle использует табличное пространство TEMP. Если каждый пользователь начнет кидать запросы с ORDER, это может привести к резкому падению производительности.



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

Здравствуйте, Mika Soukhov, Вы писали:

FD>>Это широко распространенное заблуждение.

MS>Тоесть, таких неграмотных как я много? Ну чтож, скучать не будем.

Я вот раньше тоже думал, что констрейнты — это не бизнес-правила, пока
старика Дейта не почитал.

Хотя, если мыслить логически, то все совершенно ясно.

По определению, бизнес-правила — правила, описывающие организацию бизнеса (в общем, есть разные определения,
но все они означают приблизительно одно и тоже).

Возьмем, скажем, торговую компанию. В базе данных у нас будут присутствовать, допустим,
таблицы Orders для заказов и OrderItems для позиций заказа, между которыми
создан Foreign Key. Смысл этого ключа в переводе на нормальный язык будет означать
"Заказ состоит из нескольких позиций. Каждая позиция заказа принадлежит одному
и только одному заказу". То есть самое что ни на есть правило, описывающее
процесс ведения бизнеса.

(Если быть совсем точным, то здесь Foreign Key не совсем точно описывает реальность,
поскольку он допускает ситуацию, когда некоторой записи в таблице Orders не соответствует ни
одной записи в таблице OrderItems. То есть резрешаются пустые заказы, не содержащие
позиций, чего в жизни не бывает.)

Аналогично Primary Key для таблицы Orders означает "Каждый заказ имеет уникальный номер,
чтобы отличать его от других заказов" и так далее.


MS>Любой автоматизированные бизнес в мире (выращивание бананов и продажа оружейного плутония) объединяют как минимум три бизнес-правила

Какие ?

> потречена ни одна сотня человеко\лет.
rdbms оракла ~ 30 лет, для пары сотен человеко лет там должно в ядре ковырятся не более 30 человек из 10,000 штатных сотрудников

2_Oleg_
может перед критикой хотя бы oracle concepts попробуете осилить, ну и историю ИТ полистать ...

Здравствуйте, Cyberax, Вы писали:

C>Flying Dutchman wrote:
>> Indeed, foreign key constraints in particular are an important case of
>> *business rules* in general.
>> (В самом деле, ограничение по внешнему ключу является частным случаем
>> *бизнес-правила*.)
>> Так что ограничение целостности являются бизнес-правилами.
C>Достаточно редко объекты в БД соответствуют 1-в-1 реальным
C>бизнес-объектам. Так что FKC — это один из _способов_ задавать
C>бизнес-правила, но не самый мощный.

Интересно, а какой способ задавать бизнес-правила более мощный ?

Здравствуйте, pkarklin, Вы писали:

P>А какие проблемы с юнит-тестированием серверного кода? И, простите, зачем мне ООП в реляционной СУБД?! Свят, свят, свят...

В PL/SQL уже давно есть ООП.

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

А если еще вспомним про всякие reporting'и, analizing'и b т.п....