Используйте внешний ключ, естественный ключ и уникальный ключ
Реляционная база данных, мощное и надежное хранилище данных, используемое почти всеми разработчиками программного обеспечения. Он хорошо работает, даже если вы используете RDB без реляционных функций.
В зависимости от ситуации неиспользование этих ограничений может быть лучшим вариантом. Но если у вас есть возможность создать приложение с нуля, используйте внешний ключ, естественный ключ и уникальный ключ для обеспечения качества продукта. Если вам не нужны эти функции, это означает, что RDB может быть неправильным выбором.
Общие оправдания
Представление
Эта таблица будет иметь миллионы строк. Если мы наложим на него уникальное ограничение, мы не сможем сохранить SLA, потому что команда UPDATE займет много времени. Давайте не будем этого делать.
Удаление ограничения — это последний вариант производительности. Вы можете найти несколько способов повышения производительности, таких как сегментирование, кластеризация, реплика чтения и масштабирование. Обычно мы можем получить достаточно памяти, диска и процессора по разумной цене.
Временные данные
Все изменения таблицы вставляются вместо обновления существующей записи, чтобы мы могли получить прошлое состояние. Это означает, что ограничение естественного ключа нельзя установить для таблицы.
Удобно ли хранить любые данные в одной базе данных? Это также звучит как откладывание проблем. Почему бы вам не разделить таблицу на последнюю таблицу состояний и исторические данные или не использовать базу данных временных рядов. Мне нравится использовать Graph DB для хранения временных данных сущностей и отношений. Запрашивать ER в определенное время проще, чем SQL.
стол бога
В этой таблице продуктов представлены все продукты компании, такие как книги, музыка, фильмы и т. д. Поэтому в нем много пустых столбцов, таких как «ISBN», которые предназначены только для записи книги. Также в нем есть избыточные столбцы, такие как «музыкальный жанр», «жанр книги» и «жанр фильма», потому что эти справочные таблицы внешнего ключа различны.
Иногда удобно, если все данные хранятся в одной таблице, но это также рискованно, потому что мы можем не заметить, когда музыкальная запись имеет ценность в ISBN или запись книги не имеет ценности в ISBN. Это нормально, пока вы поддерживаете кодовую базу. Эта бомба замедленного действия взорвется после того, как вы уйдете.
Закрепить знания предметной области
Избавьтесь от гибкости определения таблицы, используя эти ограничения. Это скажет вам о несоответствии между знанием предметной области и реализацией.
Например,
Допустим, столбец package_product_id соединяет книги и музыку с таблицей package_products. Он связан с ограничением внешнего ключа.
В пакете «подарок на день рождения» 1 книга и 2 ноты. Если пользователь хочет удалить подарок на день рождения, но не хочет удалять книгу и музыку, ограничение внешнего ключа не позволяет этого сделать. Разработчик может заметить, что в определении модели что-то не так, и исправить ER на изображении ниже. Если в таблице нет ограничения, разработчик не заметит этой проблемы.
Используйте эти ограничения, если вы не хотите постепенно испортить продукт косвенными средствами.
