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

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

Есть такое правило (которое, кстати, мотивирует писать тесты): стоимость исправления внесённого бага возрастает по мере продвижения бажного кода к проду.
Не все ошибки в MR удаётся найти, особенно в проекте на 50+ таблиц и больших MR (а некоторые задачи принципиально не решаются рекомендуемыми MR). Исправить внесённый баг разработчику до создания первых коммитов (и без написания кучи кода, завязанного на этот баг) дешевле чем процесс переписки в рамках code review, последний дешевле, чем найти баг тестировщиком. Плюс, примерно с этого момента появляется немаленький шанс, что баг заметят только на проде.
Сильно нагруженные таблички не следуют нагружать триггерами лишний раз (знаю примеры, когда и fk-констрейнты выключали), но в остальных случаях делать базовую валидацию целостности (не бизнесовых правил, а именно логики схемы) - нормальный вариант. Ну и на практике, такое требуется нечасто, в основном - во всяких хитрых справочниках (и их повреждение может довольно серьёзные последствия иметь).

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

Если имеются в виду правила типа запрета напрямую работать с таблицами вместо использования crud-слоя, то в некоторых случаях это может сильно сказываться на производительности. Возможно, не для всех СУБД это влияние одинаково (честно, не замерял, как с этим в mssql).

Естественно круд даёт оверхеды, но взамен он даёт очень большие преимущества архитектуры и безопасности

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

Допустим есть update затрагивающий n строк и меняющий три столбца, ссылающихся на другие таблицы.
Можете показать как заменить три FK на процедуру с xact_abort = on?
А потом объяснить почему это будет эффективнее?

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

Ну как обычно :) Ответа на вопросы нет, зато есть наезд :)

Вас никто не заставлял писать о нарушении целостности данных триггерами и о замене FK на xact_abort = on
А продемонстрировать и то и другое вы не в состоянии.

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

А что, то что написано вчера уже протухло?
А ответов на элементарные вопросы вопросы так и нет...

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

1. Вы говорили, что триггер не обеспечивает целостность. Это подразумевает выполнение вне родительской транзакции.
2. Если вы не в курсе как и в каких транзакциях работают триггеры, то вообще не можете судить об их применимости.
3. Вопрос об FK все еще без ответа. Опять что-то не так было спрошено и не соответствует вами написанному?

1.Да, триггер не обеспечивает логическую целостность данных. Те если вы будете считать сумму в соседней табличке всех строк, она у вас разойдется.
2. Откуда вы взяли что я не в курсе?
3. Ну напишешь при инсерте ещё один инсерт в справочник в явной транзакции, шо ты как маленький

Давайте конкретней

Что такое "соседняя таблица"? Почему сумма разойдется? Причем тут триггер?
Если бы были в курсе, не писали бы подобных опусов.
Был задан вполне конкретный вопрос про FK с вполне конкретными вводными. Если не в состоянии дать конкретный ответ - так и скажите.

Теперь клоуну и ответ не ответ

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

Съеби просто и не тегай меня. Естественно что клоун пришел к такому выводу. Дам я тебе скрипты, будут тебе не те скрипты, дам я тебе книжку, издатель не тот. С такими как ты давно все ясно.

Чтд 😊
Гонору - много. Знаний - мало.

Проследуйте в личку, там можете сраться, сколько угодно