2009-02-03 3 views
3

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

ответ

10

Вы должны следовать принципам нормализации, а не заботиться о большом количестве столбцов в таблице. Бизнес-требования будут управлять объектами, их атрибутами и их отношениями, а абсолютное число не является «правильным».

11

Есть ли связь между числом столбцов и хорошим процессом нормализации?

Короче говоря, нет. Нормированный таблица 3NF будет иметь столько столбцов, сколько это необходимо, при условии, что

данные в таблице зависит на ключ, весь ключ, и ничего , но ключ (да поможет мне Кодда).

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

+0

+1 для фразы: «данные в таблице зависят от ключа, целого ключа и ничего, кроме ключа (так что помогите мне Codd)». Какая прекрасная линия ... Я удивлен, что никогда не слышал об этом раньше. Вы сделали это или у вас есть источник? –

+0

Я считаю, что впервые услышал это в Библии SQL Server 2005 Пол Нильсен - http://www.amazon.co.uk/Server-2005-Bible-Paul-Nielsen/dp/0764542567/ref=sr_1_1?ie=UTF8&s = books & qid = 1233667734 & sr = 8-1 Я просто сделал поиск и не смог найти фразу, но почти уверен, что это было отсюда –

+0

Согласованная, удивительная фраза, +1. – RedFilter

3

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

+0

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

+0

Я согласен, что это может быть «разумный» индикатор, но не более того. Я просто посмотрел на некоторые таблицы в схеме базы данных Cisco IPCC, и в некоторых таблицах имеется более 90 столбцов. Конечно, существует ряд постоянных вычисляемых столбцов, но я думаю, что пункт, который я пытаюсь сделать, - это ... –

+0

, что характер данных будет определять количество столбцов в таблицах (в моем примере платформа VoIP-телефонии). BTW, схема базы данных Cisco IPCC обоснованно нормализована. –

4

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

CREATE TABLE Person 
    Person_ID int not null primary key, 
    Forename nvarchar(50) not null, 
    Surname nvarchar(50) not null, 
    Username varchar(20) null, 
    PasswordHash varchar(50) null 

Эта таблица представляет собой человек, но явно не все люди обязательно должны быть пользователями, следовательно, Имя пользователь и PasswordHash поля обнуляемые. Однако возможно, что на 1 или 2 порядка больше людей, чем есть пользователи.

В таком случае мы могли бы создать таблицу User для хранения полей Username и PasswordHash с отношением «один к одному» с таблицей Person.

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

Редактировать

Благодаря Стефани (см комментарии) этот метод, по-видимому называется «Vertical Разметка»

+0

По крайней мере, скажите ему название этой техники: вертикальное разделение. –

+0

@Stephanie: Почему это так важно? – AnthonyWJones

+1

Ну, так как я сомневаюсь, что вы полностью исчерпали весь объем знаний, известных о вертикальном разделении, OP может захотеть, да, я не знаю, Google это. Google не вернется с хорошими ответами: «Это то, что сказал AnthonyWJones на SO», но для Vertical Partitioning. Если бы у меня было больше репутации, я бы исправил это для вас. –

0

Каждый столбец должен иметь прямое и исключительное отношение к первичному ключу. Если у вас есть атрибут-тяжелый элемент, который можно сделать только для упрощения модели. Любая попытка разбить на несколько таблиц будет контрпродуктивной и бессмысленной.

Смежные вопросы