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

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

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

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

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

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

MaterialsProperties
MaterialID
PropertyID
PropertyValue varchar (3000)

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

[property] InspectionDate> [DateTimeValue][property] serialNr = 35465488

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

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

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

Ответы на вопрос(2)

например вIntMaterialProperties, CharMaterialPropertiesи т. д. Это будет:

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

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

 user8049821 авг. 2009 г., 16:56
Я не знал, что у такого дизайна БД есть имя («Методы модели значений атрибутов сущностей»). Я должен отдать должное bkm. Я бы отметил ваш ответ как «полезный», но, видимо, мне не хватает репутации. Еще раз спасибо вам обоим за ваши быстрые и очень полезные ответы.
 Adamski21 авг. 2009 г., 13:13
Нет проблем. Вы можете отказать или принять мой ответ, если хотите (попытка вымогать очки репутации).
 user8049821 авг. 2009 г., 12:07
Изначально я думал о том, чтобы добавить дополнительные столбцы значений, специфичные для каждого типа данных, в таблицу MaterialsProperties. Но ваше решение будет обеспечивать лучшую производительность и эффективность хранения. Большое спасибо!
Решение Вопроса
Так как пользователи могут вводить свои собственные имена свойств, я предполагаю, что каждый запрос будет включать сканирование таблицы свойств (в вашем примере мне нужно найти propertyid из [inspeDDate]). Если таблица свойств велика, ваше объединение также займет много времени. Вы можете попробовать и оптимизировать, денормализуя и сохраняя имя с помощью propertyID. Это был бы денормализованный столбец в таблице MaterialsProperties.Вы можете попробовать добавить тип свойства (int, char и т. Д.) В таблицу materialsproperty и разбить таблицу по типу.Посмотрите на методы объектно-реляционного сопоставления / модели значений атрибутов сущности для оптимизации запросов.Поскольку у вас уже есть много данных (2 миллиона записей), проведите некоторый анализ данных, чтобы увидеть, есть ли повторяющиеся группы свойств для многих материалов. Вы можете поместить их в одну схему, а остальные - в таблицу EAV. Смотрите здесь для деталей:http://portal.acm.org/citation.cfm?id=509015&dl=GUIDE&coll=GUIDE&CFID=49465839&CFTOKEN=33971901
 user8049821 авг. 2009 г., 12:11
На самом деле, конечные пользователи выбирают свойства из выпадающего списка. Итак, у меня есть propertyID с самого начала. Опция интеллектуального анализа данных кажется очень интересной, спасибо за указание на это!

Ваш ответ на вопрос