LSVСвязи (констрайнты) будут мешать разными способами.
Каким образом FOREIGN KEY CONSTRAINT может мешать?

Кот Матроскинstomskyпропущено...

Каким образом FOREIGN KEY CONSTRAINT может мешать?
Ну в принципе они могут мешать, конечно - их проверки небесплатны и увеличивают требуемые ресурсы на обновление данных
Кот, блин, ну ты такой троллинг запорол!!!
Разумеется я знаю про эти якобы "тормоза". Но я ни разу не слышал серьезных аргументов в продолжение разговора об этих тормозах.
Поэтому надеюсь, что LSV и объяснит.

scfДоводы против:
- требуется большая скорость вставки и другие способы оптимизации уже реализованы
- вставка сущности в сложную нормализованную базу может быть делом нетривиальным
Ну т.е. надо принять за правило, что отказываться от внешних ключей надо там, где уже пожертвовали нормализацией?
Ведь даже если мы откажемся от FOREIGN KEY (как технической возможности РСУБД) мы же не откажемся от бизнес-требования "обеспечить ссылочную целостность данных"? Нас же не устроит, что, например, "Строка заказа" может существовать без привязки к "Заказу"? А если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования?

LSVА если не устроит, то как без FOREIGN KEY будем обеспечивать выполнение этого бизнес-требования? Просто напишите логику, где всегда будет шапка у строки заказа. Только и всего.
Давай на примере. Например, есть такая структура данных (T-SQL):


По-моему, между этими таблицами должна быть связь внешним ключом между столбцами: Orders.OrderId -> OrderDetails.OrderId.
Но мы внешние ключи решили не использовать.
Что должно быть в слое бизнес-логики для того, чтобы запрос на вставку строки в OrderDetails не привел к нарушению ссылочной целостности?
Я правильно понимаю, что вместо этого:


надо сделать что-то вроде этого:


?
Ну, само собой, это все надо выполнить с нужным уровнем изоляции и наложением блокировки на выбранную в Order строку, чтобы между SELECT-ом и INSERT-ом другой пользователь эту строку не стер.
Если я понял правильно, то ИМХО быстрее отработает с внешним ключом...

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

LSVИли импорт из сырого источника, где логика уже изначально нарушена.
Ну в этом случае данные, которые надо загрузить в базу, просто некорректны с точки зрения модели данных бизнес-логики.
Я таких случаях в той же базе делаю отдельные таблицы для первоначальной (черновой) загрузки таких данных (может быть, не нормализованные и, да, может быть, без внешних ключей). Этакая маленькая свалка данных в базе данных. Но потом пользователю через интерфейс программы все равно приходится наводить порядок и перегонять эти данные в основные таблицы базы, в которых уже есть внешние ключи.
Все-таки просто загрузить данные в базу - мало. Главное как их потом можно будет использовать: строить отчеты или производить расчеты. А люди, которые пишут аналитические запросы, в праве рассчитывать на то, что данные в базе корректны. И "потерянных" строк в Detail-таблицах не будет. Я не прав?

LSVНарушение логики ФК всегда можно обнаружить и правильно отреагировать (н-р заново создать шапку или удалить/переместить осиротелые строки)
Как ты создашь заново строку в таблице Orders??? Откуда ты возьмешь ее реквизиты (номер, дату, КлиентId и пр.)? Заставишь пользователя заносить с бумаги?

LSVКароч есть масса случаев, когда приходится работать с несогласованными данными.
Лучше иметь поврежденные данные (кот. вероятно можно поправить), чем вообще ничего не иметь, кроме кучи ошибок вставки. Удалить их всегда успеется.
Т.е. когда надо позволить иметь бардак в базе данных (хотя бы кратковременно)? :)
Ну тогда, конечно, возразить нечего :)

LSVНи одна тиражная ERP система не использует ФК. И это абсолютно правильно для постоянно эволюционирующих систем.
Хорошо, при должной прямоте рук разработчиков и достаточном их количестве без FOREIGN KEY обойтись можно. Можно даже без уникальных первичных ключей обойтись. Обычных индексов одних наделать и нормально. Но это, по-моему, из области: "у нас такая большая и богатая контора, что мы можем позволить себе разработать свою СУБД (свой ORM, свой Web-сервер и пр.)". На этом сайте реально все работают в таких конторах?
Чтобы отказаться от FOREIGN KEY в промышленной СУБД необходимо между нею (СУБД) и клиентом (написанным не тобой) воздвигнуть стену из сервисов доступа к базе. И обязать клиента модифицировать БД только посредствам этих сервисов.

LSVВсе равно нравятся констрайнты ? ОК. Используй их.
Договорились. :)
Я только за то, чтобы после того, как на вопрос "нужны ли констрейнты" ответить "нет", все-таки добавить "но в этом случае ты рискуешь... и потому тебе придется ...".

LSVзы: никто внятной их нужности так и не привёл. Ждёмс...
Лично для меня тут довод один: это еще одна (да, не совершенная, но чертовски эффективная "в пределах своей компетенции") линия защиты от:
1. Своих же собственных ошибок в коде, содержащем логику работы с БД.
2. Ошибок в коде других (написанных не мной) клиентов, содержащих логику работы с БД.
Если ты уверен в своей непогрешимости, то аплодирую стоя...

LSVАбсолютно все удаления (в т.ч. логические) делаются соотв.процедурами, кот. делают много бизнес-проверок с внятными ответами на ошибки. Поэтому случайно удалить важную инфу невозможно.
Т.е. на каждую сущность (читай таблицу) - отдельная процедура "Delete_<Entity>"?