Определить универсальную модель данных для пользовательских типов продуктов

Question

Я хочу создать каталог продуктов, в котором предусмотрена сложная информация о каждом из типов продуктов в каталоге. Типы продуктов имеют совершенно разные данные, связанные с ними; некоторые с только общими данными, некоторые с несколькими дополнительными полями данных, некоторые со многими полями, специфичными для данного типа продукта. Мне нужно легко добавлять новые типы продуктов в систему и уважать их конфигурацию, и мне бы хотелось получить советы о том, как проектировать модель данных для этих продуктов, а также о том, как обрабатывать постоянство и поиск.

Некоторые продукты будут очень общими, и я планирую использовать общий интерфейс для редактирования этих продуктов. Продукты, которые имеют расширяемую конфигурацию, связанную с ними, получат новые представления (и контроллеры), созданные для их редактирования. Я ожидаю, что все пользовательские продукты будут иметь собственную модель, но будут иметь общий базовый класс. Базовый класс будет представлять общий продукт, не имеющий пользовательских полей.

Примеры продуктов, которые необходимо обработать:

1. Универсальный продукт
   • Описание
2. лампочка
   • Описание
   • Тип (с перечислением флуоресцентных, накаливания, галогеновых, светодиодных)
   • 1020 * Мощность *
   • Стиль (перечисление наводнений, пятен и т. Д.)
3. Холодильник
   • Описание
   • Марка
   • Модель
   • Стиль (с перечислением в доменной модели)
   • Информация о водяном фильтре
     • Номер детали
     • Описание

Я предполагаю использовать MEF для обнаружения типов продуктов, доступных в системе. Я планирую создавать сборки, содержащие модели типов продуктов, представления и контроллеры, помещать эти сборки в корзину, а приложение обнаруживать новые типы продуктов и отображать их в навигации.

1. С использованием SQL Server 2008, как лучше всего хранить продукты этих различных типов, добавляя новые типы без необходимости расширения схемы базы данных?

2. При поиске данных из базы данных, как лучше всего перевести эти полиморфные сущности в их правильные доменные модели?

---

Обновления и уточнения

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

2. Я поговорил с Нихилком более подробно о его справке по SharePoint. В частности, он говорил об этом: http://msdn.microsoft.com/en-us/library/ms998711.aspx. На самом деле это выглядит довольно привлекательно. Нет необходимости разбирать XML; и существует некоторая индексация, которая позволяет выполнять простые и быстрые запросы к данным. Например, я мог бы сказать «найти все 75-ваттные лампочки», зная, что первый столбец int в строке - это мощность, когда строка представляет лампочку. Что-то (NHibernate?) В уровне приложения будет определять сопоставление типа продукта со схемой пользовательских данных.

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

Answer 1

Используйте таблицу UserData в стиле Sharepoint, в которой есть набор строковых столбцов, набор столбцов типа int и т. Д. И столбец типа.

Затем у вас есть список таблиц типов, который определяет схему для каждого типа - его свойства и конкретные столбцы, с которыми они сопоставляются в таблице UserData.

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

Answer 2

Подводя итог, давайте рассмотрим рассматриваемые варианты хранения информации о продукте: 1) какой-то формат xml в базе данных

2) аналогично предыдущему сообщению о наличии x числа столбцов, определенных типом (подход с использованием sharepoint)

3) через общую таблицу с определениями имени и типа, хранящимися в справочной таблице, и значениями во вторичной таблице со столбцами id, propertyid, value (аналогично # 2, однако этот подход предоставит неограниченную информацию о свойствах

4) некоторый гибрид вышеуказанного варианта, в котором таблица продуктов будет иметь x общих столбцов (для хранения свойств, общих для всех продуктов) с y определенными пользователем столбцами (это может быть m целочисленного типа и n типов varchar). Это может быть лучшее из # 2 и нормализованной структуры, как если бы вы знали все свойства всех продуктов. Вы получите наилучшую производительность sql для наиболее часто используемых вами свойств (вероятно, общих для всех продуктов), но при этом сможете использовать настраиваемые столбцы для определенных свойств для каждого продукта.

Есть ли другие варианты? На мой взгляд, я считаю 4 выше лучшим гибридом комбинаций.

• 1012 * Дэйв *

Answer 3

Я думаю, вам нужно использовать модель данных вроде -

Таблица продуктов

• ProductId (PK)
• ProductName
• Подробнее

Таблица свойств

• PropertyId (PK)
• ProductId (FK)
• ParentPropertyId (FK - ссылка на себя для классификации свойств)
• PropertyName
• PropertyValue
• PropertyValueTypeId

Таблица поиска значений свойств

• PropertyValueLookupId (PK)
• PropertyId (FK)
• LookupValue

А затем на основе этого создайте динамическое представление. Вы можете использовать колонку PropertyValueTypeId для идентификации типа, используя соглашение, например (0-строка, 1-целое число, 2-число с плавающей запятой, 3-изображение и т. Д.) - но в конечном итоге вы можете хранить только все, что не указано. Вы также можете использовать этот столбец, чтобы выбрать шаблон элемента управления для отображения соответствующего свойства для пользователя.

Вы можете использовать таблицу поиска Value, чтобы вести поиск определенного свойства (чтобы пользователь мог выбрать его из списка)

Answer 4

Джеф,

В настоящее время мы используем поле XML в таблице «Продукты» для обработки всех данных, относящихся к продукту. Таким образом, наша таблица «Продукты» имеет несколько общих полей, которые разделяют все продукты, XML, который содержит все, что нужно конкретному продукту дополнительно, и несколько вычисляемых полей, которые вводятся в XML и отображают некоторые из часто запрашиваемых полей как «виртуальные» поля Таблица продуктов (например, «Стиль» будет установлен на то, что определяет текущий продукт, или NULL, если у продукта нет свойства Style).

Пока что мы достаточно гибко подходили к этому подходу - если вы создадите несколько приличных схем XSD для своего XML, вы даже можете создать прокси-классы C # для этих полей.

Хорошо работает для нас - объединяя лучшее из мира реляционных и XML.

Марк

Answer 5

Я думаю, вам следует избегать Inner Platform Effect и создавать таблицы для своих специализированных объектов. Вы будете писать конкретный код для управления ими, так почему бы не иметь правильных таблиц поддержки?

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

Answer 6

Поместите как можно большую часть ожидаемой общей структуры в традиционную нормированную модель 3NF, а затем добавьте соответствующие столбцы XML.

Я не вижу, чтобы MEF (или любой другой ORM) мог делать все это прозрачно.