Подход к общему дизайну базы данных - PullRequest
Новая
       19

Подход к общему дизайну базы данных

2 голосов
/ 21 августа 2009

Приложение, с которым я сталкиваюсь у клиента, выглядит так:

  • позволяет конечным пользователям вводить «материалы».
  • К этим материалам они могут добавлять любое количество «свойств».
  • Свойства могут иметь любое значение типа: decimal, int, dateTime и varchar (длина варьируется от 5 символов до больших кусков текста),

По сути, схема выглядит так:

Материалы
MaterialID int not null PK
MaterialName varchar (100) не нуль

Свойства
PropertyID
PropertyName varchar (100)

MaterialsProperties
MaterialID
PropertyID
PropertyValue varchar (3000)

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

  • [свойство] инспекцияДата> [DateTimeValue]
  • [property] serialNr = 35465488

Угадайте, как это работает с таблицей MaterialsProperties, содержащей почти 2 миллиона записей.

База данных была изначально создана под SQL Server 2000, а затем перенесена на SQL Server 2005

Как это можно сделать лучше?

Ответы [ 2 ]

1 голос
/ 21 августа 2009

Вы можете рассмотреть возможность разделения таблицы MaterialsProperties по типу, например, в IntMaterialProperties, CharMaterialProperties и т. д. Это будет:

  • Разделите ваши данные.
  • Разрешить потенциально более быстрый поиск для поиска целочисленного (или другого числового) типа.
  • Потенциально снизить затраты на хранение.

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

0 голосов
/ 21 августа 2009
  1. Так как пользователи могут вводить свои собственные имена свойств, я предполагаю, что каждый запрос будет включать сканирование таблицы свойств (в вашем примере мне нужно найти propertyid [inspeDate]). Если таблица свойств велика, ваше объединение также займет много времени. Вы можете попробовать и оптимизировать, денормализуя и сохраняя имя с помощью propertyID. Это был бы денормализованный столбец в таблице MaterialsProperties.
  2. Вы можете попробовать добавить тип свойства (int, char и т. Д.) В таблицу материалов свойств и разбить таблицу по типу.
  3. Посмотрите на методы модели реляционного сопоставления объектов / атрибутов сущностей для оптимизации запросов.
  4. Поскольку у вас уже есть много данных (2 миллиона записей), выполните некоторый анализ данных, чтобы выяснить, существуют ли повторяющиеся группы свойств для многих материалов. Вы можете поместить их в одну схему, а остальные - в таблицу EAV. Подробности смотрите здесь: http://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901
...