Всегда не был фанатом того, что бы шить какую либо сложную логику на уровне бд. Вызвал на своей модельке save() или update() и сидишь довольный, пока не увидишь, что приложка упала с ошибкой «Procedure pizduy_debajit_database() edned with status code 1». Вот здесь твое приключение и начинается. На каком-то поле был триггер, триггер вызывал процедуру, процедура дергала другое поле, на котором тоже триггер. В итоге продебажив 5 различных процедур, ты все таки фиксишь ошибку в коде, что бы через неделю забыть об этом И снова получить эту же ошибку, но уже в другом месте.

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

Но тут главное не словить крайность, где все поля в базе имеют тип строки, нет никаких ключей, связей. Как раз таки эту логику и надо выносить на уровень базы. Связи объектов, свойства полей(какие не нулл, какого типа, какие уникальные и т.д.), то как сами объекты выглядят - это все мы делаем обязательно, иначе можем получить в каждой таблице по одному столбу, в котором будет храниться json строка с данными.

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