Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
Может кто-нибудь объяснить какие могут быть причины отказа от FK?

Здравствуйте, DeathKnight, Вы писали:

DK>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

навскидку
1) быстродействие
2) версионирование записей (каждое сохранение добавляет новую версию записи)

> Может кто-нибудь объяснить какие могут быть причины отказа от FK?

чаще всего это тупость и непрофессионализм "проектировщика"

Здравствуйте, α, Вы писали:

α>Здравствуйте, DeathKnight, Вы писали:

DK>>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

α>навскидку
α>1) быстродействие
α>2) версионирование записей (каждое сохранение добавляет новую версию записи)

а можно подробней про быстродействие? и какие-нибудь примеры?

Здравствуйте, DeathKnight, Вы писали:

DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

1. Незнание матчасти.
2. Попытка использовать субд не по назначению.

Здравствуйте, DeathKnight, Вы писали:

DK>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?
Если вообще не используют — то либо не умеют, либо база была автоматом мигрирована с Access и потом не трогалась (то есть, частный случай "не умеют").
Если не используют в части таблиц — то это может быть оправдано: либо это промежуточные ETL таблицы, либо критичные к быстродействию.

Здравствуйте, DeathKnight, Вы писали:

DK>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

База могла генериться каким-нибудь ORM

Здравствуйте, DeathKnight, Вы писали:

DK> а можно подробней про быстродействие? и какие-нибудь примеры?

Проверка внешних ключей замедляет DML.
Внешние ключи обычно индексируются (иначе получим еще больший удар по производительности). Поддержка индексов также замедляет DML и ухудшает параллельность (за счет дополнительных блокировок).

Пример предлагаю построить самостоятельно.

Здравствуйте, DeathKnight, Вы писали:

DK>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

Если данная практика распространяется на некоторые таблицы, а не на всю БД, то вполне может быть оправданное решение.

1. Отсутствие внешних ключей, позволяет сэкономить на проверке ссылочной целостности, что в целом положительно сказывается на производительности операций модификации данных.
2. Отсутствие связей позволяет избежать одного из вида взаимоблокировок с участием внешних ключей, который авторы описывают в статье Eliminating Deadlocks Caused By Foreign Keys with Large Transactions Если полениться разобраться в причинах и возможных способах устранения, то самым простым решением будет разрыв связи.
3. В качестве альтернативы используют CHECK CONSTRAINT
4. На днях коллеги спросили совета — как поступить лучше, а именно разорвать связь между двумя таблицами или переписать часть кода по времени равную половине дня. В условиях сжатых сроков проекта, я посоветовал разорвать связь и вернуться к этому вопросу в лучшие времена.

Здравствуйте, Olaf, Вы писали:

O> я посоветовал разорвать связь и вернуться к этому вопросу в лучшие времена.

Т.е. близко к никогда

Здравствуйте, Olaf, Вы писали:

O> 2. Отсутствие связей позволяет избежать одного из вида взаимоблокировок с участием внешних ключей, который авторы описывают в статье Eliminating Deadlocks Caused By Foreign Keys with Large Transactions Если полениться разобраться в причинах и возможных способах устранения, то самым простым решением будет разрыв связи.

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

Офтопик.

Я не до конца понял механизм дедлока. Почему на уровне read committed snapshot, clustered index scan спотыкается на блокировках, установленных еще не завершившейся транзакцией? Можешь пояснить?

Вообще статься небрежная какая-то. Ни версия сервера не указана, ни даже дата написания.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, DeathKnight, Вы писали:

DK>> а можно подробней про быстродействие? и какие-нибудь примеры?

W>Проверка внешних ключей замедляет DML.
W>Внешние ключи обычно индексируются (иначе получим еще больший удар по производительности). Поддержка индексов также замедляет DML и ухудшает параллельность (за счет дополнительных блокировок).

W>Пример предлагаю построить самостоятельно.

хм. спасибо. с большего стало понятно.

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, Olaf, Вы писали:

O>> 2. Отсутствие связей позволяет избежать одного из вида взаимоблокировок с участием внешних ключей, который авторы описывают в статье Eliminating Deadlocks Caused By Foreign Keys with Large Transactions Если полениться разобраться в причинах и возможных способах устранения, то самым простым решением будет разрыв связи.

W>В их-то случае отказаться от связи было нельзя, они моделировали ETL процесс и внешний ключ использовался для валидации входных данных.

Возможно, ну ETL ведь он тоже разный бывает, все от способностей зависит

W>Офтопик.

W>Я не до конца понял механизм дедлока. Почему на уровне read committed snapshot, clustered index scan спотыкается на блокировках, установленных еще не завершившейся транзакцией? Можешь пояснить?

W>Вообще статься небрежная какая-то. Ни версия сервера не указана, ни даже дата написания.

Не знаю, но мне статья понравилась. Оригинал ее находится в книге SQLCAT’s Guide to: Relational Engine, как я понимаю от MSFT. Просто я опубликовал ссылку на статью, чтобы заинтересованные люди не копались в pdf, а сам сайт к этой статье не имеет никакого отношения. В книге есть дата публикации Сентябрь 2013, и версии сервера к которым относится информация SQL Server 2005 to 2012. Точное местоположение статьи в книге – Секция 8, Страница 180.

Я думаю ключевой момент здесь следующий…

Note SQL Server acquires shared locks when validating foreign keys, even if the transaction is using read committed snapshot (read committed using row versioning) or snapshot isolation level. Be mindful of this when examining deadlock graphs from transactions when these transaction isolation levels are used. If you see shared locks, check to see whether the locks are taken on an object that is referenced by a foreign key.

Здравствуйте, Olaf, Вы писали:

O> Я думаю ключевой момент здесь следующий…

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

Здравствуйте, Olaf, Вы писали:

O> W>В их-то случае отказаться от связи было нельзя, они моделировали ETL процесс и внешний ключ использовался для валидации входных данных.

O> Возможно, ну ETL ведь он тоже разный бывает, все от способностей зависит

Честно говоря, мне сложно представить смоделированную там ситуацию в реальности. Если объем обрабатываемых данных таков, что требует параллельной загрузки в 24 и даже 48(!) процессов (и железо способно это переварить!), то там будут применяться уже другие, более надежные решения для ухода от блокировок. В первую очередь партиционирование.

Здравствуйте, DeathKnight, Вы писали:

DK>Встречал уже несколько проектов, в которых при использовании реляционных СУБД не используют внешние ключи в таблицах.
DK>Может кто-нибудь объяснить какие могут быть причины отказа от FK?

Первая по частоте причина -- идиотизм...
Напомню, что 95% людей на Земле -- идиоты.

Здравствуйте, DeathKnight, Вы писали:


α>>1) быстродействие
α>>2) версионирование записей (каждое сохранение добавляет новую версию записи)

DK>а можно подробней про быстродействие? и какие-нибудь примеры?

После создания FK все операции в дочерней таблице, которые являются операциями вставки, или операциями изменения, затрагивающими поля,
участвующие в FK, требуют проверки наличия соотв. записи в родительской таблице, т.е. т.н. FK look up. Это операция, которая
может дать O(Nрод), но проблема в том, что FK в 99% случаев ссылается на PK в родительской таблице, или на уникальный индекс там же,
и FK loop up занимает только лишь O(log(Nрод)), что очень быстро, но всяческие идиоты-проектировщики об этом забывают. Они говорят,
что у них есть фронт-енд, и бэкенд, где ссылочная целострость проверяется 20 раз (на самом деле, 1-2), и нет необходимости
делать это ещё раз непосредственно в БД. Но они забывают, что не все операции с БД производятся через фронт и бэк.

Поэтому все доводы против FK в БД -- абсурд.

Здравствуйте, wildwind, Вы писали:

W>Проверка внешних ключей замедляет DML.
Это не совсем верно. Даже наоборот, наличие внешних ключей может существенно ускорить DML.

W>Поддержка индексов также замедляет DML и ухудшает параллельность (за счет дополнительных блокировок).
А вот это совсем не верно. Наличие индексов как раз увеличивает параллельность и уменьшает вероятность ожидания на блокировках. Если конечно все с умом делать.
Пример предлагаю построить самостоятельно )

Здравствуйте, IB, Вы писали:

IB> Это не совсем верно. Даже наоборот, наличие внешних ключей может существенно ускорить DML.


IB> Наличие индексов как раз увеличивает параллельность и уменьшает вероятность ожидания на блокировках. Если конечно все с умом делать.

Согласен, бывает и так, и эдак. Как всегда, it depends.