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

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

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

Вам нужно разделить, что такое «логика базы данных» и что «логика приложения». Мой обычный пример - это определение того, что ваша организация подразумевает под «FullName» для клиента. Представьте, что вы пишете код в своем приложении, который объединяет имя и фамилию в поле полного имени. Позже вы добавляете средний начальный столбец (или решаете включить уже существующий средний начальный столбец) как часть полного имени.

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

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

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

Логика зависит от базы данных - MySQL, например, не имеет поддержки рекурсивных запросов и аналитических функций. PostgreSQL получил аналитику только недавно - SQL Server имеет и то, и другое с версии 2005; Oracle - с 9i.

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

ORM давно известны тем, что отлично подходят для несложных запросов, и я рад видеть, что они развились до поддержки использования хранимых процедур/и т.д. ...Что полностью уничтожает цель использования ORM - теперь вы снова пишете код, специфичный для базы данных, ради производительности. Это как в анекдоте про решение чего-то с помощью regex - теперь у вас две проблемы...

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

Заключение

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

Если вы уже используете Ruby on Rails, значит, вы взяли на себя обязательство использовать программное обеспечение, о котором существуют различные мнения. Правильно или неправильно, мнение Rails по этому вопросу заключается в том, что логика находится внутри приложения Rails. Она даже доходит до того, что сама обеспечивает ссылочную целостность через ActiveRecord и его ассоциации, хотя вы, конечно, можете обеспечить это в базе данных, если хотите, добавив ограничения в свои таблицы. Многие разработчики Rails не беспокоятся об этом, либо по незнанию, либо по собственному желанию.

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

Я сам твердо стою на позиции "логики приложения".

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

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

Есть логика данных и есть логика приложения. База данных должна знать все о логике данных, приложение - о логике приложения. Логика данных может храниться внутри базы данных в хранимых процедурах, представлениях, правилах и т. Д. Oracle, PostgreSQL, SQL Server и т. Д. Имеют очень мощные инструменты для поддержки этого.

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

Что касается PostgreSQL, обратите внимание на различные PL: PL / pgSQL хорош, PL / perl и PL / ruby ​​могут быть более интересными для разработчиков perl и ruby.

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

Я создаю свои структуры данных нормализованным, гибким способом, обычно используя только типы данных и ограничения ссылочной целостности. Данные управляются приложением ("матерью"), которое реализует любые правила, необходимые для целостного домена. Если разрозненным (или сторонним) приложениям нужен доступ к этим данным, они не должны подрывать "мать" и обращаться непосредственно к хранилищу данных, а использовать методы SOA для связи с ней, прося ее предпринять действия и реагируя на результаты (включая неудачи), которые она им возвращает.

Я думаю об этом следующим образом. Если я хочу получить доступ к данным электронной почты моей компании, я не обращаюсь к ним напрямую, где они хранятся на диске. Это было бы мучительно, поскольку мне пришлось бы разбираться в структурах данных, прежде чем я смог бы что-то сделать. Вместо этого я взаимодействую с приложением почтового сервера (Exchange Server, в моем случае) с помощью методов SOA (WebDAV, CDO, LDAP и т.д.). Это приложение обеспечивает уровень абстракции для запроса данных электронной почты, календаря или контактов, для отправки электронной почты, создания контактов или встреч, управления календарями и т.д.

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

В общем, да, в основном по причинам, которые вы только что упомянули.

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

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