Как вы строите расширяемую модель данных

Question

Я думаю о создании приложения электронной коммерции с расширяемой моделью данных с использованием NHibernate и Fluent NHibernate. Имея расширяемую модель данных, я имею возможность определять сущность Product и позволять пользователю в приложении расширять ее новыми полями / свойствами с различными типами данных, включая пользовательские типы данных.

Пример: Продукт может иметь дополнительные поля, такие как: Размер - int Цвет - строка Цена - десятичная Коллекция ColoredImage - имя, изображение (например, «Red», red.jpg (двоичный файл))

Дополнительным требованием является возможность фильтрации продуктов по этим дополнительным / расширенным полям. Как мне это реализовать?

Заранее спасибо.

Answer 1

Я думаю, что эта ссылка описывает то, что вы хотите ...

http://ayende.com/Blog/archive/2009/04/11/nhibernate-mapping-ltdynamic-componentgt.aspx

Дополнительная информация о динамическом компоненте:

http://www.mattfreeman.co.uk/2009/01/nhibernate-mapping-with-dynamic-component/ http://bartreyserhove.blogspot.com/2008/02/dynamic-domain-mode-using-nhibernate.html

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

Если честно, я не знаю, что вы можете запросить такую ​​сущность, используя свойство "attribute", но если бы мне пришлось угадывать, я бы сделал для нее оператор IN.

Answer 2

Одним из параметров является модель EAV (Entity-Attribute-Value).

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

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

В основном у вас есть

Entity (Id) (например, ваша таблица продуктов) Атрибут (Id, ColumnName) Значение (EntityId, AttributeId, значение)

Вы можете иметь несколько дополнительных таблиц метаданных.

Значение должно быть лучше нескольких таблиц, одна для типа. Например: ShortStringValue (EntityId, AttributeId, значение nvarchar (50)); LongStringValue (EntityId, AttributeId, значение nvarchar (2048)); MemoValue (EntityId, AttributeId, значение nvarchar (max)); IntValue (EntityId, AttributeId, значение int);

или даже полный тип: ColorComponentsValue (EntityId, AttributeId, R int, G int, B int);

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

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

Есть несколько моментов, на которые следует обратить внимание: , Каждое значение занимает место для хранения внешних ключей , Например, блокировка на уровне строк будет вести себя иначе для таких запросов, что может привести к снижению производительности. , Может привести к увеличению размеров индекса.

На самом деле, в тесте с малой глубиной, мое решение EAV превзошло его статический аналог в таблице из 20 столбцов в запросе с 4 столбцами, включенными в критерии.

Answer 3

Я ищу похожую вещь и только что нашел N2 CMS (http://n2cms.com), которая реализует расширяемость домена весьма удобным способом. Она также поддерживает запросы к полям расширения, что важно. Единственный недостаток, который я обнаружил, заключается в том, что он реализован с использованием HQL, поэтому потребуется некоторое время для его повторной реализации, чтобы можно было выполнять запросы с использованием QueryOver / Linq, но основная идея и сопоставления присутствуют здесь. Посмотрите на классы ContentItem, DetailCollection, ContentDetail, их сопоставления и QueryBuilder / DetailCriteria.

Answer 4

Другой вариант - использовать нереляционные базы данных, которые обычно подходят для такого рода вещей.

NOSQL базы данных (couchDB, mongoDB, cassandre ...) позволяют динамически определять ваши propretyfields, вы можете добавлять поля в свой класс продукта в любое время.

Answer 5

Возможным вариантом будет сохранение всех дополнительных полей в структуре XML и использование XPath / XQuery для их извлечения из базы данных. Каждая расширяемая сущность в вашем приложении будет иметь поле XML, например ExtendedData, которое будет содержать все дополнительные свойства.