Какой использовать? EAV или Blobs в базе данных?

Question

В настоящее время я работаю над переработкой системы данных нашего приложения. По сути, он разработан таким образом, чтобы люди могли добавлять все пользовательские поля, которые им нужны, с помощью всего лишь нескольких постоянных / всегда существующих полей.

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

Сейчас мы смотрим на EAV, но, похоже, не намного лучше. По сути, у нас есть много различных типов полей, так что будет таблица StringValues, IntegerValues ​​и т. Д., Которая делает вещи намного хуже.

Мне интересно, может ли использование BLOB-объектов JSON или XML в базе данных быть лучшим решением, особенно потому, что в большинстве случаев, когда мы извлекаем что-либо из этих таблиц, нам нужна вся строка. Проблема заключается в том, что нам нужно иметь возможность создавать отчеты и для этих данных. Ни одно решение не позволяет легко настраивать пользовательские запросы. И поиск по такой базе данных больших двоичных объектов, безусловно, будет кошмаром производительности при запуске отчетов.

Каждая «строка» должна иметь от 15 до 100 (возможно, больше) атрибутов / столбцов, связанных с ней.

Мы используем SQL Server 2008, и наше приложение, взаимодействующее с базой данных, является веб-приложением C # (например, ASP.Net).

что вы думаете? Использовать EAV или BLOB-объекты или что-то еще полностью? (Кроме того, да, я знаю, что база данных без схемы, такая как MongoDB, была бы здесь великолепна, но я не могу убедить моего босса использовать ее)

Answer 1

А как насчет типа данных xml?Расширенный запрос возможен против этого типа.

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

Answer 2

Одной интересной особенностью SQL-сервера является тип sql_variant.Он полностью поддерживается в .NET и довольно прост в использовании.Преимущества в том, что вам не нужно создавать столбцы StringValue, IntValue и т. Д., А только один столбец значения, который может содержать все простые типы.

Этот очень специфический тип поддерживает параметр EAV, IMHO.1006 *

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

Answer 3

Создайте таблицу с вашими известными столбцами и разреженными столбцами «X», используя последовательное имя, такое как DataColumn0001, DataColumn0002 и т. Д. Когда есть определение для нового столбца, просто переименуйте столбец и начните вставлять данные.Большим преимуществом разреженного столбца является его индексируемость.

Дополнительная информация по этой ссылке .

Answer 4

Что вы делаете, так это STUPID с базой данных, которая не поддерживает ваш тип данных. Вам следует работать со средой, которая отвечает вашим потребностям, включая базы данных NoSQL, такие как RavenDB, MongoDB, DocumentDB, CouchBase или Postgres в RDMBS, чтобы назвать несколько.

По сути, вы используете инструмент в качестве, для которого он не был предназначен, и он специально пытается ограничить вас в достижении успеха. Решения NoSQL для баз данных часто используют JSON в качестве базового хранилища, поскольку JSON по своей сути не имеет схемы. Хотите добавить недвижимость? Конечно, вперед, хотите добавить целую коллекцию суб? Конечно, идти вперед. Частично базы данных NoSQL были созданы специально для устранения жестких требований к схемам СУБД.

2015 Редактировать: Postgres теперь изначально поддерживает JSON. Это жизнеспособный вариант для СУБД. Мой ответ все еще правильный, что вам нужно использовать правильный инструмент для решения проблемы. Это мир постоянства полиготов.