Нужно ли создавать таблицу для всех повторяющихся данных?

Question

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

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

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

Answer 1

В общем, я рекомендую использовать ENUM, если вы заботитесь о правильном вводе данных.Например, если вы хотите найти всех людей, чей пол - MALE, было бы здорово, если бы вы могли гарантировать, что в поле пола всегда будет прописная буква M, а не строчная буква m или буква G для слова «парень», потому что перед-конец приложения содержал ошибку.

Если вы заботитесь о правильном вводе данных и есть дополнительная информация, связанная с концепцией, я рекомендую выделить ее в отдельную таблицу.Например, если «бизнес-тип» связан с TAX_RATE, вы, вероятно, захотите создать таблицу business_types.

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

Answer 2

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

Вы читаете не ту книгу. Нормализация иногда включает перемещение атрибутов из одного отношения в другое; нормализация никогда не предполагает замену идентификационного номера на текст.

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

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

Вы также можете ограничить значения с помощью ограничения CHECK, но когда вы обнаружите новое действительное значение, вам придется изменить схему. Если вы используете таблицу и ограничение внешнего ключа, вам просто нужно вставить строку в таблицу. В вашем случае ограничение CHECK подойдет для «пола»; таблицы, вероятно, были бы лучше для "бизнес-типа" и "приветствия".

Answer 3

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

Answer 4

Смысл нормализации состоит в том, чтобы убедиться, что одна и та же информация об одном объекте не сохраняется дважды (потому что она может и, вероятно, может стать непоследовательной). Очевидно, что разные объекты в одной и той же таблице будут иметь одинаковые поля, и, конечно, многие из них будут иметь F и много M. Это не проблема. Единственное, что вам не следует делать, это хранить избыточные данные на запись , например, GENDER: f, TERM_OF_ADDRESS: Ms - это действительно лучше сделать с помощью таблицы поиска.

Кроме того, вам не нужно нормализовать только потому, что разные таблицы в вашей схеме имеют похожие поля, например, TYPE или GENDER. Просто убедитесь, что это действительно независимые таблицы! Например, если вы описываете сотрудников в таблице EMPLOYEE, и эта таблица содержит информацию о поле, то пол, вероятно, также не должен храниться в связанной таблице HEALTH_RECORD, даже если это может иметь медицинское значение.

Answer 5

Для таких вещей, как пол, я бы сказал, что достаточно простого поля CHAR. то есть «M», «F», «U» (неизвестно). Однако для Business Type я бы посоветовал разбить это на отдельную таблицу. С одной стороны, бизнес-тип, вероятно, будет достаточно длинным, вам может потребоваться добавить больше в любой момент времени, и вы можете изменить бизнес-тип.

Answer 6

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

Answer 7

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

Для таких полей, как пол , было бы полезно содержать описательную информацию, такую ​​как мужчина / женщина, а не коды, такие как M / F или True / False.

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

Answer 8

Вы можете использовать ENUM (Mr, Mrs) или ENUM (Male, Female) для таких данных.

См. http://dev.mysql.com/doc/refman/5.1/en/enum.html