|
Подобъем предварительные итоги:
Размещение бизнес-логики на сервере приложений:
1. Независимость от типа СУБД
За редкими исключениями МИФ!
В качестве элементарного примера:
В общем-то синтаксис того же SQL отличен во всех базах, например, в MySQL:
SELECT DAYOFMONTH(MAX(post_date)) AS lastday,MONTH(MAX(post_date)) AS lastmonth ...
В Oracle:
SELECT TO_CHAR(MAX(post_date), 'DD') AS lastday, TO_CHAR(MAX(post_date), 'MM') AS lastmonth
Вместо функции NOW() или CURTIME(), Oracle имеет SYSDATE
В отличие от Mysql, где можно использовать:
INSERT INTO mytable SET mycolumn=myvalue
в Oracle INSERT процедура происходит только в формате
INSERT INTO mytable (ID,mycolumn) VALUES (1,"myvalue")
Возможно проблема с форматами данных типа date.
to_date('2008-08-13','yyyy-mm-dd');
И это я не затронул даже 100 части подводных камней.
2. Независимость от DBA
Отчасти достижима, т.к. если все писать максимально однотипно и не использовать большую часть функционала, включая и базовый, ни одной из СУБД, то можно обойтись самыми примитивными познаниями и лишь изредка привлекать специалистов со стороны.
Плата за это – приложение требующее в десятки, а то и в тысячи раз больше ресурсов. Это можно сравнить с желанием использовать кирпич и для строительства, и для забивания гвоздей, и для чесания спины, и убийства мух и в качестве доски для рисования. Кому не нравится сравнение с кирпичом, могут подставить сюда синхрофазатрон.
Результат соответствующий.
Еще один вариант, заставить разработчиков самим приобрести знания DBA – но тогда о какой независимости идет речь?
3. Одно место хранения бизнес-логики облегчает изменение и тестирование оной.
Отчасти верно, но:
- во-первых, обычно часть этой самой логики все равно ложится/дублируется на клиенте и СУБД, хотя бы в виде ограничений уникальности и foreign key.
- во-вторых, такая система становится крайне уязвима при попытках работы с ней вне единого сервера приложений. Практика показывает, что если еще можно ограничить внешние приложения на операциях вставки, добавления и удаления использованием API сервера приложения, то с операциями выборки данных это получается не очень, часто вообще никак.
Впрочем БЛ на СУБД здесь мало чем поможет. За одним НО - число приложений, умеющих работать с СУБД, на несколько порядков больше, чем с нашим сервером приложений.
- в-третьих, мы вынуждены тестировать как собственно бизнес-логику, так и функционал низкоуровневого взаимодействия с СУБД. Т.е. по сути количество тестов, как минимум, не уменьшается.
- в-четвертых, по мере развития системы и накопления информации, вполне возможно появление такого кол-ва новой функциональности, которое все равно заставит разделить, а во многом и продублировать, бизнес-логику между различными приложениями, например, бухгалтерской и складской программами. Иначе единый сервер приложений превратится в монстра.
Т.е. сама идей о централизации бизнес-логики в одном месте часто оказывается самообманом.
Да, мы можем вынести ее из СУБД, но централизации это не даст.
4. Реализация бизнес-логики на сервере приложений снимает большую часть нагрузки с СУБД.
- Если эта логика в основном лежит вне СУБД это совершенно верно, в т.ч. для того и используется многозвенный принцип работы.
- Если же сервер приложений пытается подменить логику, лежащую на стороне СУБД, то вместо этого имеем значительное повышение нагрузки на СУБД и сети передачи данных. Т.е. не только ничего не выигрываем, но занимаемся прямым вредительством.
Размещение бизнес-логики в СУБД:
- Если всей, то тут обсуждать нечего, IMHO это если и реализуемо, то разумным такой подход можно назвать только сильно не выспавшись.
Возвращаемся на круги своя, с чего собственно и начинали и вокруг чего ходит дискуссия уже 12 страниц:
- Размещать бизнес-логику наиболее связанную с целостностью и непротиворечивостью данных и завязанную на низкоуровневые операции в ХП.
- Прочую бизнес-логику из СУБД убрать.
Увы, но при этом ранее упомянутая проблема взаимодействия внешних программ с системой останется и простого решения нет ни в каком варианте. :(
- Все внешние по отношению к СУБД программы должны осуществлять операции по низкоуровневым манипуляциям с данными, за исключением выборки данных, только посредством ХП.
- Выборку данных внешнее приложение должно осуществлять только через view.
- ХП должны предоставлять интерфейс уровня API операций, а не API таблицы, т.е. никаких insertIntoTableAppUsers, а только что-то типа addNewWebUser.
- Скорость смены технических средств работы с данными значительно меньше, чем скорость смены средств разработки, поэтому вероятность того, что нашей разработки придется переползать с какого-нибудь DBASE на Visual FoxPro, оттуда на .NET, а оттуда на JAVA, а оттуда на что-то еще, что гарантированно появится года через три, гораздо выше, чем вероятность смены СУБД.
А тогда, чем меньше было реализовано на среднем слое, тем проще будет выйти из ситуации.
Кстати, последнее соображение гораздо важней, чем многим кажется исходя из сегодняшней моды.
Хотя все вышеизложенное и не является серебряной пулей, но является разумным компромиссом.
Так?
|
