Какой дизайн базы данных вы предпочитаете; один с реальными физическими отношениями или тот, который имитирует это?

Question

Какова лучшая практика при разработке реляционной базы данных?Чтобы иметь физические отношения между таблицами (фактическая линия, проведенная из таблицы в таблицы) или имитировать только отношения?

Например:

Таблица A имеет столбцы

ID, Name

TableB имеет столбцы

ID, CNIC, TableA_ID 

Теперь TableA_ID не имеет фактического ограничения внешнего ключа, но по-прежнему хранит значение, которое отображаетсяк столбцу ID в Таблице A.

Я считаю, что позднее это хорошо, и я считаю, что первое замедляется и имеет проблемы с каскадной работой?

Answer 1

Реляционная модель не содержит никаких физических связей. Одно отношение (таблица) может иметь ссылку на другое, используя пары «ключ - внешний ключ» («ключ» не может быть первичным). Для обеспечения целостности ссылок требуется ограничение внешнего ключа. Ограничение внешнего ключа должно использоваться в вашем дизайне «по умолчанию».

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

Answer 2

Одним из основных заданий базы данных является обеспечение целостности данных .
Частью целостности данных является ссылочная целостность .
Реляционные базы данных обеспечивают ссылочную целостность с ограничениями внешнего ключа.

Снимите ограничение, и вы удалите базу данных для защиты от поврежденных данных.

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

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