Базы данных обеспечивают 3 вида декларативной целостности:
- Целостность домен - тип поля и ограничение CHECK.
- Целостность ключ - Ограничение PRIMARY KEY или UNIQUE.
- Ссылочная целостность - FOREIGN KEY.
A ключ уникально идентифицирует строки в таблице.Все ключи логически эквивалентны, но по практическим причинам один из них выбран как «основной», а остальные считаются «альтернативными» (есть некоторые сложности, связанные с NULL, но давайте не будем вдаваться в подробности).
С другой стороны, FOREIGN KEY является своего рода «указателем» из одной таблицы в другую, где сама СУБД гарантирует, что этот «указатель» никогда не сможет «болтаться» .Внешний ключ ссылается на (первичный или альтернативный) ключ в «родительской» таблице, но конечной точке «потомка» не обязательно должен быть сам ключ (и обычно это не так).
- Когда строка изменяется или удаляется из родительской таблицы, это изменение либо каскадно к дочерней таблице (ON [ОБНОВЛЕНИЕ / УДАЛЕНИЕ] [CASCADE / SET NULL / SET DEFAULT]), либовся операция блокируется (ON [UPDATE / DELETE] RESTRICT).
- Если дочерний элемент вставлен или изменен, он проверяется по родительской таблице, чтобы убедиться, что это новое значение существует там.
Ограничения изменяют , что означает данных. Индексы , с другой стороны, не меняют значения данных - они приведены здесь исключительно по соображениям производительности .Некоторые базы данных даже позволяют вам иметь ключ без базового индекса, хотя обычно это плохая идея с точки зрения производительности.Индекс под первичным ключом называется «первичным индексом», а все остальные индексы являются «вторичными».
Кстати, есть «вторичный индекс» и «альтернативный ключ», но не существует такой вещи, как«вторичный ключ».
Я не совсем уверен, какова ваша цель дизайна, но я предполагаю, что что-то вроде этого было бы неплохой отправной точкой:
Я не вижу смысла извлекать подробности в отдельные таблицы , если они всегда находятся в отношении 1: 1 с элементом.
--- EDIT --
Некоторые вопросы, которые вам нужно задать себе, прежде чем вы сможете прийти к оптимальному дизайну базы данных:
Существует ли реальное соотношение 1: 1 между элементом и деталямиили это на самом деле 1: 0..1 (то есть некоторые детали являются необязательными?).
- Если 1: 1, использование столбцов является наиболее естественным представлением.Кстати, приличная СУБД не будет иметь проблем с обработкой 100 столбцов.
- Если 1: 0..1, вам придется решить, использовать ли столбцы с поддержкой NULL или отдельные таблицы.Просто имейте в виду, что большинство СУБД действительно эффективно хранят значения NULL (обычно это просто небольшое растровое изображение на строку), поэтому разделение данных на другую таблицу может не принести вам много пользы, а на самом деле может существенно снизить производительность запросов из-за возросшей потребности вСОЕДИНЕНИЕ.
Предопределены ли все виды деталей (т. Е. Можете ли вы с уверенностью сказать, что вам не нужно будет добавлять новые виды деталей позже в приложенииlifecycle)?
- Если да, просто используйте столбцы.
- Если нет, добавление столбцов в существующей большой базе данных может быть дорогостоящим - достаточно ли дорого, чтобы гарантировать использование отдельной таблицы,на ваше усмотрение.
Можно также рассмотреть обобщение всех деталей в виде пар имя / значение и представление их в одной таблице 1: N (здесь не показана).Это очень гибко и «развивается», но имеет свой собственный набор проблем.
Как вы собираетесь запрашивать данные? Это важная вещь и может существенно повлиять начтобы использовать подход «столбцы» или «отдельная таблица», индексирование и т. д. *
Кстати, 1: 0..1 с отдельными таблицами можно смоделировать следующим образом ...
... и 1: 1 можно смоделировать следующим образом ...
... но это вводит циклическую зависимость, которая должна обрабатываться особым образом (обычно откладывая один из FOREIGN KEY).
1: N детали, конечно, являются другим вопросом и, естественно, моделируются с помощью отдельных таблиц.
Поскольку вы говорите, что «деталь 1» и «деталь 2» равны 1: (0 ..) 1, а «деталь 3» равна 1: N, ваша «обновленная» модель данных будет выглядеть примерно так:
Кстати, в приведенной выше модели используются идентифицирующие отношения, которые приводят к более "естественным" ключам. Неидентифицируемый подход отношений / суррогатных ключей будет выглядеть так:
У каждого подхода есть свои преимущества, но этот пост уже становится немного длиннее;) ...