Организация таблиц базы данных - большое количество свойств - PullRequest
Новая
       36

Организация таблиц базы данных - большое количество свойств

0 голосов
/ 21 июня 2011

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

До сих пор я держал его в таблице «UserInfo», связывая User и UserInfo как One-To-Many (ведение журнала всех изменений).Поместить его в одну таблицу «UserInfo» не очень приятно, и, по крайней мере, в модели базы данных это будет выглядеть грязно.Какое решение?

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

1 Ответ

1 голос
/ 21 июня 2011

Если это только 30 свойств, я бы рекомендовал просто создать 30 столбцов. Это не слишком много для современной базы данных.

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

Альтернативное решение - в этом блоге вы найдете отличное решение для хранения большого количества динамических атрибутов без схемы: Как FriendFeed использует MySQL .

Соберите все свойства в некотором формате и сохраните их в одном столбце TEXT. Формат является полуструктурированным, то есть ваше приложение может разделять свойства при необходимости, но вы также можете добавлять больше в любое время или даже иметь разные свойства для строки. XML, YAML или JSON являются примерами форматов или некоторых форматов сериализации объектов, поддерживаемых языком кода вашего приложения. 

CREATE TABLE Users (
  user_id SERIAL PRIMARY KEY, 
  user_proerties TEXT
);

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

CREATE TABLE UserBirthdate (
  user_id BIGINT UNSIGNED PRIMARY KEY,
  birthdate DATE NOT NULL,
  FOREIGN KEY (user_id) REFERENCES Users(user_id),
  KEY (birthdate)
);

SELECT u.* FROM Users AS u INNER JOIN UserBirthdate b USING (user_id)
WHERE b.birthdate = '2001-01-01';

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

...