Динамическая база данных / ключ - значение / сущность - ключ значение Дилемма - PullRequest
1 голос
/ 23 декабря 2011

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

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

Есть два варианта, которые я могу придумать.

Вариант 1 - Динамически создаваемые таблицы

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

Вариант 2 - сущность - ключ - шаблон значений

Это единственный реалистичный вариант, который я могу придумать, где у меня есть 5 структур таблицы:

EntityTypes

EntityTypeID int

EntityTypeName nvarchar (50)

Сущности

EntityID int

EntityTypeID int

FieldTypes

FieldTypeID int

FieldTypeName nvarchar (50)

SQLtype int

FieldValues ​​

EntityID int

FIeldID int

Значение nvarchar (MAX)

Поля

FieldID int

FieldName nvarchar (50)

FieldTypeID int

Таблица "FieldValues" будет работать немного как таблица фактов хранилища данных, и все мои вставки / обновления будут работать, заполняя табличный параметр "Key / Value" и передавая его в SPROC (чтобы избежать множественных вставок / обновлений ).

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

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

Теперь мои вопросы!

  • Кто-нибудь может предложить другой подход или схему, отличную от этих двух вариантов?
  • Будет ли возможен второй вариант для наборов данных среднего размера (максимум 1 миллион строк)?
  • Есть ли дальнейшая оптимизация для варианта 2, который я мог бы использовать?

Любое направление и советы высоко ценится!

Ответы [ 3 ]

2 голосов
/ 23 декабря 2011

Лично я бы просто использовал базу данных «noSQL» (ключ / значение), например MongoDB .

Но если вам нужно использовать реляционную базу данных, вариант 2 - это путь. Хорошим примером такой модели является Словарь данных Alfresco (Alfresco - это система управления контентом предприятия). Его дизайн аналогичен тому, что вы описываете, хотя они имеют несколько столбцов для значений полей (для каждого простого типа, доступного в базе данных). Если вы добавите к этому хорошую систему кэширования (например, Ehcache ), она должна работать нормально.

1 голос
/ 23 декабря 2011

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

  • Ваша масштабируемость для варианта 2 будет во многом зависеть от ширины пользовательских объектов. Сколько полей можно создать динамически? 1 миллион объектов, если у каждого объекта по 100 полей, может быть перетаскиванием ... Эффективное индексирование может повысить производительность.

  • Для другого варианта - у вас может быть одна таблица данных с несколькими строковыми полями, несколькими двойными полями и несколькими целочисленными полями. Например, таблица с String1, String2, String3, Int1, Int2, Int3. Во второй таблице есть строки, которые определяют пользовательский объект и отображают ваше «CustomObjectName» => String1, и тому подобное. Хранимая процедура, читающая INFORMATION_SCHEMA и некоторый динамический sql, сможет читать таблицу схем и возвращать строго типизированный набор записей ...

  • Еще один вариант (для последних версий SQL Server) - сохранить строку с идентификатором, именем типа и полем XML, содержащим документ XML, содержащий данные объекта. В MS Sql Server это может быть запрошено напрямую, а может быть даже проверено по схеме.

0 голосов
/ 31 октября 2014

Лично я бы потратил время на то, чтобы определить как можно больше атрибутов, чем использовать EAV для всего. Конечно, вы знаете некоторые атрибуты. Тогда вам нужен только EAv для вещей, которые действительно зависят от клиента.

Но если все должно быть в формате EAV, то путь к базе данных nosql - это путь. Или вы можете использовать базу данных Relationsla для некоторых вещей и базу данных nosql для остальных.

...