Сколько внешних ключей слишком много?

Перейдя через эту статью: http://diovo.com/2008/08/are-foreign-keys-really-necessary-in-a-database-design/

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

Например, предположим, что у меня есть основная таблица, используемая для хранения списка информации о детали машин, которую другие программы ссылаются со следующими столбцами:

ID
Имя
Цвет
Цена
Единицы измерения
Категория
и т.д...

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

Ответ 1

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

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

Рассмотрение производительности должно быть довольно ужасным, прежде чем я захочу пожертвовать правильностью для производительности.

Ответ 2

Каждый проект является компромиссом конкурирующих целей, поэтому есть очень мало простых ответов (кроме неправильных).

Я бы, конечно, поставил дискретные меры, такие как имя, цвет, категория, единица измерения и т.д. в свои собственные таблицы ключей. Переменные меры (стоимость, количество единиц и т.д.) Не так много, если у вас нет единиц в пакетах стандартного размера (т.е. Только 1, 6, 12 и т.д.)

Ответ 3

Самый простой способ создания базы данных - начать с требований. В одной классической методологии требования суммируются в модели ER (Entity-Relationship). В этой модели отношения между сущностями не придуманы, они обнаружены. Если они лежат в пределах объема информации, которую должна покрыть база данных, то они являются частью модели. Период.

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

Конечно, если вы вправе изменять требования по ходу процесса проектирования, вы можете делать все, что захотите.

Ответ 4

Размерное моделирование хорошо охватывает все вопросы вашего вопроса. Наличие слишком большого количества внешних ключей может привести к ухудшению качества запросов. Kimball Group Reader - отличное введение в Dimensional Design и как перевести требования клиентов к схеме.

http://en.wikipedia.org/wiki/Dimensional_modeling

Основной вопрос: "Насколько ограничены данные?" Что касается цвета деталей машин, я бы предположил, что в любом случае лучше всего не сжигать циену и ромашку в качестве цветовых вариантов. Таким образом, таблица поиска для них была бы лучше.