Для отдельных товарищей:

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

Нельзя запрос называть транзакцией. Во-первых вводите собеседника в заблуждение, во-вторых показываете отсутствие фундаментальных знаний. // последнее, пожалуйста, не воспринимайте на свой личный счёт, ладно? :)

2 expla
expla
Для нашего случая там есть понятие подтипа. Положим есть абстрактный супертип A (лицо), и два его прямых подтипа B (физлицо) и C (юрлицо). Объект одновременно не может быть двух типов B (физлицо) и C (юрлицо). За этим следит ОРСУБД.


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

expla
А как иначе? Приложение получает на вход какие то данные, проверяет их целостность, обрабатывает и сохраняет в БД целостные данные, которые естественно проходят все проверки. Выходит проверки на уровне СУБД избыточны, это не более чем assert.

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


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