Уменьшает ли внешний ключ избыточность, если на все столбцы ссылаются?

Question

Я читал, что одним из преимуществ нормализации является уменьшение избыточности в БД. Но мне интересно, если вы в конечном итоге ссылаетесь на все столбцы в целевой таблице?

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

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

Answer 1

Правильно, экономия места составляет ОДИН из преимуществ, а не единственный.

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

Вы можете абстрагировать эту таблицу с помощью автонумера / последовательности и использовать ее в качестве PK, и сделать текущий столбец ключом-кандидатом (чтобы он оставался уникальным).

Но если оставить свой дизайн в точности так, как вы обрисовали, выгода заключается в последовательности.У вас будет только эти 12 значений ... вы не случайно введете значение для "Horrer" или "PSY-Fi"

Answer 2

Экономия места - это одно из преимуществ разделения двух таблиц.Как было сказано ранее, размещение Genre_ID вместо фактического значения, такого как «Ужас» или «Приключение», сэкономит место.

На мой взгляд, лучшая часть этого - обеспечение целостности.Если вы вставите текстовые значения в таблицу Video, что мешает вам случайно изменить значение?Теперь некоторые строки могут иметь «Приключение» или «Действие / Приключение» и так далее.Имея 2 таблицы и ссылаясь на внешний ключ, вы получите лучший контроль над тем, какие значения могут быть жанром.

Итак, не беспокойтесь о том, что вы ссылаетесь на все столбцы,особенно если в таблице очень мало столбцов.Если вы решили добавить поле идентификатора или просто сохранить таблицу из 1 столбца в качестве списка «допустимых значений», ваша цель должна заключаться в том, чтобы сначала обеспечить целостность, а затем сэкономить место или затраты на ввод-вывод.

Answer 3

Нормализация не имеет ничего общего с экономией места.Речь идет об устранении потенциальных аномалий, которые могут возникнуть в результате определенных видов избыточности.Так как нормализация определяет только логический уровень, вполне возможно, что нормализованная база данных будет физически больше или физически меньше денормализованной или ненормализованной базы данных.эффективно в хранилище - но это на самом деле связано с функциями СУБД, а не с чем-то неявным в нормализации.

Answer 4

Аномалии модификации данных

• Что, если вы добавите новый жанр?
• Является ли Sci-Fi таким же, как SciFi?
• Является ли Sci-Fi таким же, как Sci-Fi?

Становится хуже, если вы за другим столом скажете «Книги» с одинаковыми жанрами.

Answer 5

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

Answer 6

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

Answer 7

Но вы сами столкнулись с проблемой:

один столбец с дюжиной довольно статических значений, таких как «Ужас», «Научно-фантастический», «Романтика» и т. Д.

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

Answer 8

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

Answer 9

Вы также сохраните, потому что «Ужас» занимает 12 байтов в Юникоде, в то время как GenreId может быть Байт или символ (1).

Answer 10

Я бы использовал суррогатные ключи (Autonumber, Identity и т. Д.) И использовал бы их для соединения с внешним ключом вместо фактического значения.

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

В большинстве БД INT будет меньше, чем Varchar2 (20)