DenlerienНасколько использование внешних ключей снижает быстродействие?
Настолько, что в большинстве случаев их присутствие куда разумнее их отсутствия.

DenlerienЕсть ли в таком случае смысл использовать внешние ключи?
Это плохая постановка вопроса. Правильно так: когда Ваша программа будет давным-давно отлажена и проверена эксплуатацией, можно будет добавить в интерфейс администратора кнопку "повысить быстродействие на 2% путем удаления внешних ключей". И написать в инструкции: "если ваша база трещит по швам, то можно использовать эту кнопку, хотя авторы этого не рекомендуют".

DenlerienПросто у пользователей не будет возможности добавить записи с несуществующей ссылкой.
Все constraint-ы в БД - это механизм защиты в первую очередь от ошибок программиста (и разработанной им программы). Во вторую очередь - от доступа руками в базу (и он неизбежно будет, хотя бы в Вашем личном исполнении, хотя бы в виде написанных/сгенерированных Вами скриптов). О защите от пользователя в constraint-ах речи практически не идет (если прикладуха позволяет пользователю организовать и увидеть нечто типа "constraint XYZ violated" - это, мягко говоря, не очень хорошая программа.

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

DenlerienНо 2% - это несущественно. Насколько корректна эта оценка?
Взята с потолка.

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

Denis PopovАвторы могут использовать в серверном коде такие свойства внешних ключей как каскадное удаление,
Могут, конечно. Но я бы не стал.

Denis Popovили обработчики ошибки при нарушении этих самых ключей.
Хм. Вы имеете в виду стиль "попробовали - получили отлуп - попробовали иначе"? Имхо в большинстве случаев это не очень хороший стиль программирования.

Denis PopovТогда ИМХО вообще отключить не получится.
Безусловно. Я в данном случае исходил из утверждения автора, что отключение в принципе возможно.

DenlerienТ.е., например, в случае ограничения уникальности лучше сначала проверить вручную, нет ли такой записи, а потом уже добавлять или не добавлять?
Это вопрос, на который трудно ответить коротко и точно, и который по направленности не очень совпадает с тем, что я имел в виду в предыдущем ответе.

Если говорить о процедуре, суть которой - в выполнении некоего insert-а одиночной записи, то в большинстве случаев не стоит делать предварительной проверки. Причин две: во-первых, это потенциально лишняя работа, во-вторых, это вносит возможность ошибки (например, в read committed существует пауза между проверкой и добавлением, в ходе которой кто-то другой может вставить нарушающую запись).

Вопрос в том, что исключительная ситуация в большинстве случаев не должна планироваться как часть нормального рабочего процесса. Позволю себе искусственный пример - допустим, есть таблица Numbers, и задача формулируется как "вставить в нее те числа из диапазона 1..10, которые там сейчас отсутствуют). Так вот, в этом случае из вариантов


и


первый с моей точки зрения лучше. Куда лучше.

СерегаПочему? Внесение некорректных (по связям) данных в отлаженой (более-менее) программе - это исключительная ситуация.
Ключевые слова той моей фразы - "попробовали иначе". То есть ситуация не исключительная, а плановая, и соответственно обрабатывать ее как исключительную не совсем верно.

ModelR softwarerМогут, конечно. Но я бы не стал. Отчего же?
По моему опыту с каскадным удалением в итоге оказывается больше геморроя, нежели без него. Я позиционирую эту фразу как сугубо личную точку зрения (я бы не стал), не являющуюся настойчивой рекомендацией или претендующим на объективность суждением; также я не слишком хотел бы погрузиться в детальное обсуждение - почему именно. Причина - отсутствие хоть мало-мальски объективных критериев при широком спектре возможных ситуаций; в лучшем случае обсуждение получится сравнением конкретных ситуаций, эксклюзивного (плохо переносимого) опыта конкретных людей.

1024Или заказ и строки заказа. Использовать каскадное удаление
нужно.
После чего в ходе сопровождения ТЗ дорабатывается: удалять можно и нужно только строки в статусе "не выполнено", а на строки в статусе "выполнено" - ругаться.

ModelRБесспорно. Но тема несколько другая, про клиента - скорее
Вы упускаете из вида, что контекст - не только общий вопрос темы, но и конкретная фраза Дениса Попова, на которую я ответил этой. Там было сказано, что приложение может использовать обработчик исключительной ситуации, причем не на ограничение уникальности, а на внешний ключ (разница - в уникальности возникает проблема при вставке кем-то другим записи, а во внешнем ключе - при удалении), причем по контексту у меня сложилось впечатление, что имеется в виду использование обработчика исключений как часть бизнес-логики. И мой ответ ограничивался рамками именно этого аспекта.

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

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