Дизайн базы данных, огромное количество параметров, денормализация? - PullRequest
Новая
       19

Дизайн базы данных, огромное количество параметров, денормализация?

1 голос
/ 14 февраля 2011

С учетом таблицы tblProject.Это имеет множество свойств.Например, ширина, высота и т. Д. Десятки из них.

Я добавляю новый модуль, который позволяет указывать настройки для вашего проекта для мобильных устройств.Это соотношение 1-1, поэтому все мобильные настройки должны храниться в tblProject.Однако, список становится огромным, среди свойств будет некоторая неоднозначность (IE, мне придется префиксировать все мобильные поля с помощью MOBILE, чтобы Mobile_width не путать с шириной).

Насколько это плохо дляденормализовать и сохранить настройки мобильного телефона в другой таблице?Или лучший способ сохранить настройки?Свойства и становится громоздким и трудно изменить / найти в таблице.

Ответы [ 2 ]

2 голосов
/ 14 февраля 2011

Я хочу ответить на предложение @Seobander Sobolev и предоставить свое собственное.

@ Александр Соболев предлагает модель EAV . Это обеспечивает максимальную гибкость для низкой производительности и сложности, так как вам нужно объединяться несколько раз, чтобы получить все значения для сущности. Обычно вы решаете эти проблемы, сохраняя все метаданные сущности в памяти (т. Е. tblProperties), поэтому вы не присоединяетесь к ним во время выполнения. И денормализовать значения (т. Е. tblProjectProperties) как CLOB (т. Е. XML) из корневой таблицы. Таким образом, вы используете таблицу значений только для запросов и сортировки, но не для фактического получения данных. Кроме того, вы обычно заканчиваете кэшированием реальных сущностей по идентификатору, так что у вас нет затрат на десериализацию каждый раз. Проблемы, с которыми вы сталкиваетесь, - это недействительность кэша сущностей и их метаданных. Так что в целом нетривиальный подход.

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

create table properties (
    root_id int, 
    type_id int,
    height int
    width int
    ...etc...
)

Создайте уникальную комбинацию root_id и type_id, где type_id будет, например, представителем мобильного устройства - предполагая отдельную таблицу поиска в моем примере.

1 голос
/ 14 февраля 2011

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

Вы можете хранить в другой таблице или использовать еще более сложную версию с тремя таблицами. Один из них - ваш tblProject, второй - tblProperties, а второй - tblProjectProperties. 

create table tblProperties (
id int autoincrement(1,1) not null,
prop_name nvarchar(32),
prop_description nvarchar(1024)
)

create table tblProjectProperties
(
   ProjectUid int not null,
   PropertyUid int not null,
   PropertyValue nvarchar(256)
)

с внешним ключом tblProjectProperties. ProjectUid -> tblProject.uid и внешний ключ tblProjectProperties.propertyUid -> tblProperties.id

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

...