Дизайн базы данных и большие таблицы? - PullRequest
1 голос
/ 13 марта 2012

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

 [Users table]
    userId
    name
    address
    somesetting1
    ...
    somesetting50

Поскольку сайт требует больше настроек, таблица становится больше. На мой взгляд, эта таблица нормализована, все настройки зависят от userId.

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

[User object]
[UserSetting object]

и возвращать только данные для заполнения этих объектов.

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

Ответы [ 5 ]

2 голосов
/ 13 марта 2012

Я думаю, вы должны использовать несколько таблиц, таких как:

[Users table]
   userId
   name
   address

[Settings table]
   settingId
   userId
   settingKey
   settingValue

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

1 голос
/ 13 марта 2012

во-первых, не ставьте пробелы в именах таблиц!все [фигурные скобки] будут настоящей болью!

если у вас есть 50 столбцов, насколько значимыми будут все эти данные для каждого пользователя?будет много нулей?Большинство данных может даже не относиться к какому-либо данному пользователю.Представьте себе таблицы 1 к 1, где вы разбиваете «настройки» на логические группы:

Users:              --main table where most values will be stored
    userId
    name
    address
    somesetting1    ---please note that I'm using "somesetting1", don't
    ...             --- name the columns like this, use meaningful names!!
    somesetting5

UserWidgets         --all widget settings for the user
    userId
    somesetting6
    ....
    somesetting12

UserAccounting      --all accounting settings for the user
    userId
    somesetting13
    ....
    somesetting23

--etc..

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

1 голос
/ 13 марта 2012

Я бы сказал, что это плохой дизайн стола.Если у пользователя нет записи для 47 из этих 50 настроек, то у вас будет большое количество NULL в таблице, что не является хорошей практикой, а также снизит производительность (NULL должны обрабатываться особым образом).

Вместо этого укажите следующее:

Идентификатор таблицы пользователя, Имя, Фамилия и т. Д.

Идентификатор настройки, Имя_установки

Идентификатор настройки пользователя, Идентификатор настройки, Идентификатор пользователя,SettingValue

Затем вы можете присоединиться ко многим и исключить NULL

.
0 голосов
/ 13 марта 2012

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

[AttributeDef]
   AttributeDefId int (primary key)
   GroupKey varchar(50)
   ItemKey varchar(50)
   ...

[AttributeVal]
   AttributeValId int (primary key)
   AttributeDefId int (FK -> AttributeDef.AttributeDefId)
   UserId int (probably FK to users table?)
   Val varchar(255)
   ...

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

Что вы думаете об этом типе дизайна?

0 голосов
/ 13 марта 2012

Используйте несколько таблиц с соответствующими индексами, чтобы получить лучшую скорость SELECT.Используйте индексы как способ связать информацию между таблицами, используя JOIN.

...