Каковы некоторые рекомендации по настройке внешних ключей базы данных

Question

Каковы некоторые хорошие правила и недостатки, на которые следует обращать внимание проектировщикам баз данных при настройке ограничений внешнего ключа в базе данных?

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

Answer 1

Практическое правило, никогда не создавайте реляционную базу данных без связей с внешним ключом, если вы заботитесь о целостности ваших данных. Да, это может замедлить вставку / обновление данных Dow и их удаление. Это хорошая вещь, поскольку она предпринимает действия для защиты ваших данных. Без целостности данных все данных в вашей базе данных ненадежны и, следовательно, бесполезны.

Как правило, нетрудно настроить внешние ключи позже (в SQL Server вы запускаете таблицу изменений Alter для добавления ключа), сложность в этом заключается в том, что непрофессионально не добавлять их на этапе проектирования , Если у вас не было FK, весьма вероятно, что у вас есть некоторые данные, которые не соответствуют правилам отношений PK / FK и которые необходимо сначала очистить.

Answer 2

• Когда вы наследуете схему, вам придется добавить к ней ограничения.(Не только ограничения внешнего ключа.)
• Кто-то должен будет исправить неверные данные, прежде чем вы сможете добавить ограничения.
• Людям требуется много времени для исправления неверных данных.(У них есть «настоящая» работа.)

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

Поэтому я давал им пару сотен ошибок в день.Каждый день в течение шести месяцев.

Answer 3

• Не разрешать нулевые значения во внешних ключах

• Избегайте использования ограничений DEFERRABLE, даже если ваша СУБД их поддерживает.

• Рассмотрите возможность добавления опции ON UPDATE CASCADE, если вы считаете, что должны, но также учитываете альтернативы (вставьте, а затем обновите, а не обновляйте непосредственно ключ-кандидат).

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