Варианты сохранения данных в виде набора пар ключ-значение с общим ключом и типом

Question

Я играю над идеей написать еще один фреймворк, чтобы упростить разработку приложений типа «хлеб-н-бэттер» (например, создать класс с N полями, бесплатно получить редактор для этого плюс постоянство БД).

Все модели данных можно преобразовать в форму Entity-Attribute-Value :

TYPE VARCHAR(32)
ID LONG INT
NAME VARCHAR(32)
VALUE VARCHAR(64000)

возможно со второй таблицей для действительно больших полей, так что я бы сохранил ссылку в столбце VALUE на запись в таблице BLOB. Если бы у меня было настроение, я мог бы создать по одной таблице для каждого типа значения (например, int бы INTEGER, избегая всех проблем преобразования), и я мог бы использовать таблицу для определения допустимых ТИПов и т. Д.

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

Недостаток заключается в том, что для каждого объекта мне нужно прочитать N строк или начать с составления сложных запросов, содержащих N подзапросов.

У кого-нибудь есть опыт с этим? Кто-нибудь когда-либо реализовывал более крупную систему таким образом? Какие есть еще варианты для сохранения данных, кроме обычного SQL? Особенно хотелось бы услышать о гибких системах, которые легко адаптируются к изменениям в модели или позволяют «исправлять» модель (обычно у экземпляра будет имя, но для некоторых я также хотел бы добавить комментарий) , Или кто-нибудь сталкивался с чем-то пост-SQL? Следующая великая вещь?

Answer 1

Этот подход используется Amazon SimpleDB . Вы определяете domains , и у каждого домена есть строки с несколькими парами ключ / значение. Эти данные известны как «полуструктурированные».

У этого подхода есть некоторые сильные стороны. Как и ваша идея, вам не нужно определять схему базы данных. Вы можете вводить новые таблицы ad-hoc, новые столбцы для каждой строки и даже иметь столбцы, имеющие более одного значения (вместо создания отношения has_many с дополнительной таблицей). Если ваша схема изменяется, вы можете вводить эти изменения переходно, а не принудительно.

С другой стороны, вы отбрасываете десятилетия разработки на реляционную модель. У вас будет кровотечение из-за того, что ваша индексация будет либо слишком общей, либо вообще отсутствует. Агрегированные операции (группы, объединения) будут чрезвычайно медленными. Оптимизация запросов будет сложной и т. Д.

Как Amazon SimpleDB, так и Apache CouchDB решают эту проблему, делая свои базы данных высоко распределенными. Хотя это обеспечивает надежность и избыточность, у него есть собственный набор проблем, таких как разрешение конфликтов и устаревшие данные.

Исходя из вашего вопроса, вы, похоже, не можете использовать гибкие методы, поэтому я бы порекомендовал один из этих двух механизмов БД (в зависимости от того, предпочитаете ли вы платить Amazon, хотя и не очень много, или создать свою собственную настройку). Они оба допускают полностью динамическую схему базы данных. Остерегайтесь ловушек.

Answer 2

Я не использовал его, но то, что вы пытаетесь сделать, звучит как CouchDB . Вы можете заглянуть туда, прежде чем изобретать велосипед ...

Answer 3

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

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

С данными пары ключ-значение я также сохраняю тип, поэтому могу автоматически отображать соответствующие элементы управления HTML. У меня есть только основные типы: текст, многострочный, RTF, флажок, число и дата.

Answer 4

Посмотрите на базы данных XML (например, eXist ). Вы можете легко изменить свою «модель данных», изменив схему xml. И вы можете использовать мощные языки запросов, такие как XPath и XQuery.