Если в базе данных будут продублированы правила типа «у родительского объекта будет до 2 детей»

Question

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

В каких случаях дублирование таких правил оправдано? Есть ли альтернатива, чтобы избежать такого дублирования? Разве это не правило целостности данных?

Спасибо

Answer 1

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

Вы не упоминаете СУБД, поэтому вам сложно найти решение.

РЕДАКТИРОВАТЬ:

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

Кроме того, вам не нужен триггер, потому что ваш средний уровень никогда не использует DML, он просто вызывает процедуры базы данных или пакеты, которые инкапсулируют ваш CRUD. Не так ли?!

Answer 2

Я думаю, что каждый уровень системы должен обеспечивать максимальное количество ограничений, для которых она удобно разработана. Остальное вы позволите другим справиться. Я бы посчитал, что ограничения базы данных и ограничения javascript относятся к несколько одной категории; Вы делаете все возможное с доступными средствами, оставаясь разумно чистым .

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

Answer 3

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

Answer 4

Это зависит.

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

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

Весь дизайн компромисс.

Answer 5

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

Если ваше приложение имеет бизнес-уровень, у меня будут только отношения, обеспечивающие SQL, а не правила.

Answer 6

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

Answer 7

Обычно я бы не использовал эту логику на уровне базы данных. Для меня это больше похоже на бизнес-правило, которое должно жить на бизнес-уровне. Что произойдет, если это правило когда-нибудь изменится? где и в скольких местах вы хотите его обновить? Как правило, ничто не должно иметь доступ к базе данных, кроме как через ваш бизнес-уровень, и поэтому все в порядке, чтобы не реализовать его где-либо еще, но бизнес-уровень. Кроме того, триггеры беспорядочные, их трудно поддерживать, и, самое главное, их трудно отладить позже.

ИМХО в любом случае.