Считается ли это нормальным провалом формы? - PullRequest
5 голосов
/ 30 декабря 2011

При сохранении религии пользователя в «Таблице пользователей», чтобы, если вы посмотрите вниз на столбец, вы увидели «Христианин» много раз, «Мусульманин» много раз и т. Д. Считали неудачей нормальной формы? Какая форма?

Как я это вижу:

  • 1nf: Нет повторяющихся столбцов.

  • 2nf: Не существует составного первичного ключа, поэтому это не применяется.

  • 3nf: Нет зависимости от неключевого атрибута.

Хранение религии пользователя таким образом, похоже, не дает сбоя ни одной нормальной форме, однако кажется очень неэффективным. Комментарии?

Ответы [ 5 ]

6 голосов
/ 30 декабря 2011

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

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

4 голосов
/ 30 декабря 2011

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

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

Существуют и другие преимущества, кроме места хранения, для хранения их в другой таблице.,Изменить их совсем несложно.Чтобы изменить Christian на Christianity, вы можете сделать одно изменение в таблице религий, вместо того, чтобы делать потенциально дорогостоящие (если у вас много строк и религия не проиндексирована)

UPDATE users SET religion='Christianity' WHERE religion='Christian'

... вы можете сделать намного проще и дешевле

UPDATE religions SET name='Christianity' WHERE id=123

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

1 голос
/ 30 декабря 2011

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

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

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

Конечно, есть и другие способы (например, ENUM для некоторых СУБД) для хранения списка возможных значений, каждый из которых имеет свои преимущества и недостатки.

0 голосов
/ 30 декабря 2011

У этого подхода есть несколько минусов (по сравнению с использованием внешнего ключа), которые вам понадобятся, чтобы убедиться, что вы в порядке. 1 - хранилище отходов. 2 - медленнее запрашивать по религии 3 - кто-то может поместить туда данные, которые не совпадают, например, вручную вставить «Джедай» или что-то, что вы, возможно, считаете неправильным 4 - нет никакого способа иметь список возможных религий (например, если в вашей таблице нет ни одной определенной религии, например, зороастрийца), но вы все еще хотите, чтобы это было допустимой возможностью 5 - неправильная капитализация может вызвать проблемы 6 - пробел вокруг строки может вызвать проблемы

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

0 голосов
/ 30 декабря 2011

Твои обычные формы немного ошибочны.Вторая нормальная форма состоит в том, что остальная часть строки зависит от «всего ключа».Третья нормальная форма состоит в том, что остальная часть строки зависит от «ничего, кроме ключа».(Так помогите мне, Кодд).

Нет, ваша описанная ситуация не нарушает ни одну из первых трех нормальных форм.(Это может нарушить шестое, в зависимости от других факторов).

...