Дизайн базы данных для элементов с переменными атрибутами?

Question

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

E.g. Пользователь может добавить компакт-диск в категорию Музыка или DVD в категорию «Фильмы». Я не хочу ограничивать категории, которые можно добавить, или элементы, которые можно добавить к этим категориям. Пользователь может в значительной степени добавить любой элемент.

В настоящее время я использую SQL Server, и у меня есть таблица элементов с ItemId (primary), Name, Description и CategoryId (foreign), ссылающаяся на таблицу Category с похожими столбцами.

Моя проблема заключается в том, что CD и DVD имеют разные атрибуты, такие как «время работы», «возрастный рейтинг», «количество дорожек», поэтому я не могу хранить их в одной таблице, потому что у них были бы избыточные столбцы. Что делать, если пользователь добавил автомобиль с «размером двигателя», «цветным» и т. Д.?

Так я исследовал, и я думаю, что у меня есть следующие варианты:

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

Проблема: Я слышал, что динамическое создание таблиц - это плохое дизайнерское решение. Сложнее управлять и находить то, что мне нужно.

2) В таблице элементов создайте столбец строк ItemAttributeData, где я могу сохранить настраиваемую строку, такую ​​как XML-документ, содержащий атрибуты для этого конкретного элемента.

Проблема: эти атрибуты не могут быть запрошены SQL и должны быть обработаны вручную в коде.

3) Идите с решением NoSQL, таким как хранилище таблиц MongoDB или azure (это приложение ASP.NET) и создайте коллекцию элементов, в которой каждый элемент может иметь другой набор столбцов.

Проблема: Я теряю реляционное отображение из категорий к пунктам и другим таблицам, как «Пользователи» (я думаю?)

4) Объединить RDBMS и NoSQL таким образом, что схематические менее атрибуты хранятся в NoSQL itemAttributes коллекция и общие свойства элемента хранятся в реляционной базе данных. Затем свяжите их, используя itemId.

Как вы думаете, что лучше всего предлагает решение с точки зрения расширяемости и производительности?

Answer 1

Если бы я был вами, я бы выбрал еще один вариант: EAV model.

Вы можете легко создать несколько видов для CD и DVD с этой модели, которые напоминают плоские таблицы для каждой категории.

Как только вы получите его, это довольно просто. И он работает хорошо.

Answer 2

Я никогда не использую его сам, но интересным решением может быть PostgreSql + hStore Вы сохраняете Sql, и вы можете использовать полуструктурированные данные внутри столбца. Этот столбец является хранилищем ключей/значений довольно ограниченным (например, не вложенным), но индексируемым и доступным для поиска.