Каковы аргументы против или для добавления логики приложения в уровень базы данных?

ПРИМЕЧАНИЕ Аудитория программистов.se и dba.se различна и будет иметь разные точки обзора, поэтому в этом случае я думаю, что это правильно, чтобы дублировать Каковы аргументы против или для применения логики приложения в уровень базы данных? на странице programers.se.

Я не мог найти дискуссию о dba на этом уже, и исходный пост говорит все, так:

  

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

     

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

     

Что вы думаете об этом, и   что должно или не должно быть хорошо   реализовать в слое базы данных?

N.B. Я не ОП для этого вопроса, но оставил оригинальную формулировку неповрежденной.

71 голос | спросил Phil Lello 29 PMpFri, 29 Apr 2011 21:16:02 +040016Friday 2011, 21:16:02

10 ответов


53

Разнообразные мысли ...

Код вашей базы данных перейдет в вашу клиентскую технологию. Подумайте об ADO.NET -> Linq -> EF, а также различные ОРМ. В то время как вы все еще можете запустить код SQL Server 2000 из последнего millenium для всех вышеупомянутых клиентских технологий.

У вас также есть проблема с несколькими клиентами: у меня есть .net, java и Excel. Это 3 набора логики приложения.

«Бизнес-логика» не следует путать с «логикой целостности данных». Если у вас есть клиенты, начинающие транзакции и выполняющие различные проверки, это много звонков на db и длительная транзакция.

Логика приложения не масштабируется для больших объемов данных. У нас есть 50 тыс. Строк в секунду с использованием хранимых процедур. Сестра-команда, использующая Hibernate, не может получить один в секунду

ответил gbn 29 PMpFri, 29 Apr 2011 21:26:56 +040026Friday 2011, 21:26:56
38

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

В последнем Fortune 500, над которым я работал, были приложения, написанные не менее чем на 25 языках, попадающих в их базу данных OLTP. Некоторые из этих программ перешли к производству в 1970-х годах.

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

Каковы шансы?

Разве это не самый большой « не повторяйте на планете?

ответил Mike Sherrill 'Cat Recall' 30 AMpSat, 30 Apr 2011 05:43:20 +040043Saturday 2011, 05:43:20
28

Я переношу свой старый ответ на неотредактированный от программистов.se, поскольку ответы кажутся довольно поляризованными между сайтами.

  

Я знаю, что мне нужен мир   здесь, но поставить бизнес-логику в   потому что:

     
  • Вы можете разрешить пользователям бизнес-мощности прямой доступ к базе данных, а не   беспокоиться о том, что они привинчивают его (или   беспокоиться меньше, чем с   основанная на приложениях).
  •   
  • Пользователь с полномочиями может создавать новые отчеты, не ожидая появления нового программного обеспечения   выпуск.
  •   
  • Вы можете проверить код SP /TRIGGER в копии базы данных, так же, как   вы проверяете логику на основе приложений
  •   
  • Вы можете сохранить SQL для создания sp и триггеров в текстовых файлах (вы должны   делать это в любом случае для таблицы /просмотра   код)
  •   
  • Вы можете смешивать и сопоставлять языки без переноса бизнес-логики
  •   
  • Вы можете вносить изменения в бизнес-логику, не обновляя каждый бит   Программное обеспечение
  •   
  • Структура аудита изменяется так же, как вы проверяете активность базы данных -   через журнал
  •   
  • Значительно улучшена безопасность и контроль доступа к мелкому зерну (большинство   приложения на основе приложений используют   их собственной модели безопасности, поэтому данные   гораздо легче пойти на компромисс.   Реверсивное шифрование пароля не   редкость)
  •   
  • Безопасность пользователей на стороне базы данных значительно снижает вероятность повреждения /кражи   do
  •   

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

     

Ни один из них не имеет значения для   квалифицированный разработчик.

     

Интересно отметить, что большинство ответов говорят   в терминах «логики приложения», а не   «бизнес-логика», как будто программное обеспечение   не существует, чтобы обеспечить бизнес   функция.

ответил Phil Lello 2 Mayam11 2011, 06:50:18
22

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

ответил Jack Douglas 29 PMpFri, 29 Apr 2011 21:25:52 +040025Friday 2011, 21:25:52
16

Я написал свой ответ на этот в своем блоге . Мой вывод: выполнение этого в приложении просто не масштабируется, если вы считаете весь жизненный цикл приложения.

  

â € |
  3. Добавьте ограничения целостности /проверки в базовую базу данных с более сложным кодом, реализованным на языке хранимых процедур базы данных. Из этого мы получаем одно центральное место для поддержания, и мы получаем полное соблюдение правил даже для приложений, о которых мы не знаем! Мы получаем один язык для выражения бизнес-правил на всем протяжении портфеля приложений и жизненного цикла, поскольку язык jour изменяется гораздо чаще, чем база данных. И он работает на системе, которая уже столь же критически важна, как и самые важные приложения. Ошибки обрабатываются существующим кодом, который обрабатывает ошибки базы данных в этих приложениях. По-прежнему существует риск, что приложение может выйти из строя, но из трех сценариев это наименее, и только сломанное приложение нуждается в каких-либо модификациях, а не во всех из них (и большинство механизмов SP /базы данных позволят исключить сделано для одного приложения, если это действительно действительно необходимо). Думаете, это не имеет значения на вашем новом сайте или в небольшой компании? Хорошо, если ваш бизнес преуспеет, через 30 лет вы пожелаете, чтобы вы учли мою мудрость!

     

«Некоторые [возражения] Я часто слышу:

     
  • Трудно контролировать код SP с версией, развернутый в БД. Я не думаю, что это правда, чем сказать, что это трудно контролировать версию Java-код, развернутый в приложении сервер, т. е. это совсем не сложно, это обычное дело. И в Ruby-land, целые книги написаны о том, как получить код из среды разработки в производство, что-то, с чем не сталкивается никакое другое языковое сообщество. Однако версия, контролирующая хранимую процедуру, по-видимому, слишком сложна.
  •   
  • Сохраненные процедуры трудно проверить. Это странно. Для начала SPs строго типизированы; компилятор скажет вам, есть ли в коде код или нет, что не имеет смысла, а в Oracle по крайней мере рассчитает все зависимости для вас. Итак, это один набор общих тестов модулей, которые вам могут понадобиться в Ruby, удаленные с места в карьер. Чтобы проверить код OO, необходимо издеваться над тем, чтобы принудить объект во внутреннее состояние, необходимое для представления тестового сценария, - как настраивать тестовые данные по-разному? Кроме того, существует программа TAP для PL /SQL и других инструментов. Также есть отладчики и профилировщики.
  •   
  • Язык хранимой процедуры не является полнофункциональным языком. Ну, мы не пытаемся написать целое приложение только в хранимых процедурах! На большинстве выделенных языков SP есть все современные конструкции, которые вы ожидаете, и по крайней мере в Oracle вы можете использовать хранимые процедуры Java со всеми языковыми функциями, с которыми знакомы разработчики OO, или внешние процедуры на любом языке. Важно то, где логика реализована - в одном месте, рядом с данными - фактический язык - это всего лишь деталь. PL /SQL компилируется в собственный код и запускается в процессе с базой данных; нет более высокопроизводительной архитектуры, чем это.
  •   
  • Я не хочу учиться на другом языке. Оглядываясь на секунду, это огромный красный флаг любого разработчика (особенно тот, который предлагает модифицировать производственные приложения, которые могут быть на других языках в любом случае!) есть много возможностей учиться работать в любой современной среде: в типичном магазине Java могут быть Eclipse, WebLogic, Maven, Hudson, Anthill, Subversion и целый ряд других, которые вам нужно изучить, прежде чем писать одну строку приложения код. Рабочие знания языка SP с очень высоким уровнем простоты в сравнении, и, скорее всего, вам поможет специалист или администратор базы данных. Не говоря уже о том, что любимый разработчик Hibernate имеет свой собственный язык запросов ...
  •   

â € |

ответил Gaius 18 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSun, 18 Sep 2011 18:49:43 +0400 2011, 18:49:43
11

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

Кроме того, как указывал GBN выше, код SQL почти повсеместно переживает код приложения.

Хотя верно, что EF или NHibernate или LinqToSql или что-то еще позволит вам генерировать код быстрее, каждый программист, заслуживающий своей производительности, знает, что оптимизация SQL-запроса будет оптимизировать только оптимизация SQL. RDBMS понимает только SQL, поэтому вам нужно сделать все в SQL, прежде чем все будет сказано и сделано. (предполагая, что мы можем согласиться с тем, что TSQL и PLSQL по-прежнему являются SQL)

ответил jcolebrand 30 AMpSat, 30 Apr 2011 03:13:03 +040013Saturday 2011, 03:13:03
9

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

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

ответил Adam Musch 7 MarpmFri, 07 Mar 2014 18:32:05 +04002014-03-07T18:32:05+04:0006 2014, 18:32:05
6

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

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

В прошлом приложения клиентского сервера превратили мост в BL через хранимые процедуры (SP). Для таких продуктов, как Oracle и SQL Server, это было сделано раньше. Поскольку появились базы данных с открытым исходным кодом, такие как PostgreSQL и MySQL, те, кто их использует, рискуют сломать новую землю с помощью хранимых процедур в BL. PostgreSQL созрел очень быстро в этом, поскольку были реализованы не только хранимые процедуры, но и возможность создавать языки клиентов. MySQL в основном прекратил развиваться в мире хранимых процедур и вышел в урезанной форме языка со многими ограничениями. Таким образом, когда дело доходит до BL, вы полностью зависите от MySQL и языка хранимой процедуры.

Остается только один вопрос: Независимо от СУБД, должен ли BL находиться полностью или частично в базе данных?

Подумайте о Разработчике. Когда в приложении возникают проблемы, процесс отладки будет иметь хост разработчика в базе данных и из нее, чтобы следить за чередованием данных, которые могут быть или не быть правильными с перерывами. Это похоже на кодирование приложения C ++ и вызов ассемблерного кода посередине. Вы должны переключиться с исходного кода, классов и структур на прерывания, регистры и смещения И НАЗАД !!! Это приведет к отладке на том же уровне.

Разработчики могут создавать высокоскоростной метод выполнения BL в сочетании с языковыми настройками (флаги компилятора для C ++, разные настройки для PHP /Python и т. д.) через бизнес-объекты, находящиеся в памяти, а не в базе данных. Некоторые пытались свести эту идеологию к более быстрому запуску кода в базу данных, написав библиотеки, где отладка хранимых процедур и триггеров хорошо интегрирована в базу данных и, по-видимому, может быть использована.

Таким образом, разработчику предлагается разработать, отладить и сохранить исходный код и BL в двух языках.

Теперь подумайте о DBA. Администратор базы данных хочет сохранить базу данных как можно меньше в области хранимых процедур. DBA может видеть BL как нечто внешнее для базы данных. Тем не менее, когда SQL вызывает данные, необходимые для BL, SQL должен быть тощим и средним.

Теперь, для встречи умов !!!

Код разработчика SP и использует iteractive методы. DBA смотрит на SP. DBA определяет, что один оператор SQL может заменить итеративные методы, написанные разработчиком. Разработчик видит, что предложение SQL, предлагаемое администратором базы данных, требует вызова другого кода, связанного с BL, или SQL, который не соответствует нормальным планам выполнения инструкции SQL.

В свете этого конфигурация, настройка производительности и кодирование SP становятся функцией глубины и интенсивности данных BL для извлечения данных. Чем больше глубина и интенсивность данных BL, тем больше разработчиков и DBA должны быть на одной странице для объема данных и вычислительной мощности, данных в базе данных.

Заключение

Способ поиска данных должен всегда включать как лагеря разработчиков, так и базы DBA. Концессии всегда должны быть сделаны в отношении того, какие методы кодирования и парадигмы поиска данных могут работать вместе, как по скорости, так и по эффективности. Если подготовка данных для исходного кода для обработки выполняется всего за один раз до того, как код получит данные, администратор баз данных должен диктовать использование скудного и среднего SQL. Если BL - это то, с чем не работает DBA, тогда бразды правления находятся в руках разработчика. Именно поэтому администратор баз данных должен видеть себя и часть проектной команды, а не остров для себя, в то время как разработчик должен позволить администратору базы данных выполнить точную настройку SQL, если это того стоит.

ответил RolandoMySQLDBA 5 Mayam11 2011, 01:16:38
3

Это хороший вопрос, который нужно задать на веб-сайте, полном DBA. Надеемся, что большинство ответов будут «про» в отношении сохранения базы данных в состоянии ACID и, таким образом, ведения бизнес-логики в базе данных. : -)

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

ответил Ruud van de Beeten 17 +04002012-10-17T16:21:25+04:00312012bEurope/MoscowWed, 17 Oct 2012 16:21:25 +0400 2012, 16:21:25
1

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

Блокируйте, очевидно, неправильные вещи от доступа к базе данных.

  • Отбирать адреса электронной почты, которые не соответствуют каким-то основным образом.
  • Проверить длины

Когда вы углубляетесь, когда нужно принимать решения. Сервер БД - очень дорогое место, чтобы делать то, что клиент мог сделать легко. пример: форматирование данных, даты форматирования, сборки строк и т. д. сторона клиента.

Выполняете ли вы математику /обработку на клиенте или на сервере БД? Для меня это зависит от сложности и количества записей. Бизнес-логику действительно нужно делать в самой БД, так что все обрабатывается одинаково. Вы действительно должны создать API-представлений для чтения и хранения procs для записи данных в БД для сохранения головных болей в будущем.

Используйте преимущества каждого конца в своей выгоде.

ответил Matt M 24 J0000006Europe/Moscow 2014, 00:21:51

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132