Хранение структурированных данных

[MIT]

Необходимо создать внутри базы данных специфичную структуру, однако не могу додуматься как это сделать наиболее рационально.
Идей такая: в базе должны храниться описания структур и элементы, содержащие данные по этим структурам.
Сам пока додумался до создания 2х таблиц: первая содержит название структуры и ее идентификатор, а вторая - поля структур (всех): идентификатор структуры к которой поле принадлежит, название, описание (и еще чего-нибудь). Таким образом получаем возможность создания любого количества структур с любым количеством полей.
Проблема встает дальше - как хранить данные? Можно создать таблицу с сотней полей типа varchar(MAX), в надежде что больших структур у нас не будет, или же хранить данные в сериализованном виде в binary-полях, но оба эти варианта мне не нравиться из-за неуниверсальности и сложности поиска по данным.

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

MSSQL 2008

[Денис]

Я голосую за сериализацию в бинарных полях.

[alibek]

xml используй.

[Денис]

И еще один вариант:
Почему поля структуры должны непременно соответствовать полям таблицы?
Делаешь поле идентификатора записи, поле идентификатора структуры, поле имени структуры, поле имени поля структуры, поле типа поля структуры, поле значения поля структуры. И вперёд!
А потом запросом по идентификаторам и именам сможешь получить структуру со всеми полями.

UPD: Ой, я описал то же самое, что у тебя в топике, только запихнул всё в одну таблицу... В общем, тот вариант что у тебя сейчас самый лучший ИМХО, так как отвечает требованиям соглашений о дизайне структуры таблиц БД.
У тебя две таблицы, одна с названиями и индексами структур, вторая с полями, индексами и значениями. Устанавливаешь запрос по типу master-detail и получаешь значение любого интересующего поля. Врядли можно придумать что-то более оптимальное.

UPD2: ЕМНИП, этот вариант хранения данных называется не структуры а карточки. То есть, в объектной модели клиентского приложения это структуры, а в базе данных они превращаются в карточки. И обратно, соответственно.

[MIT]

xml используй

xml - это, конечно, хорошо, но надо будет еще как-то поиск осуществлять по данным, а чтение файла весьма ресурсоемко... Хотя вроде есть адаптеры данных для xml баз (речь идет, ясное дело, о .NET`е), позволяющие выполнять SQL запросы к файлам, но никогда таким не пользовался.

тот вариант что у тебя сейчас самый лучший ИМХО

Но в нем нет самого главного - в нем нет места непосредственно для хранения данных.


Пока шел домой придумал еще один вариант (основывается на моей первоначальной идее): сделать третюю таблицу, содержащую идентификатор строки (тут одна строка - одно значение), идентификатор струткуры, к которой оно относится, идентификатор поля вышеобозначенной структуры, идентификатор записи (т.е. "имя" объекта которому пренадлежит поле).

При таком раскладе можно получить:
1) Данные определенного объекта (экземпляра структуры): SELECT * FROM tblData WHERE идентификатор_записи = @id
2) Данные всех объектов из определенного поля объекта (например для поиска): SELECT * FROM tblData WHERE идентификатор_поля = @struct_field_id
3) Все обекты одного типа (созданные на основе одной структуры)
И т.п.

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

[Денис]

Такой вариант будет нормальным?

Ну да. Одна таблица Имен (Заголовков), вторая таблица Полей, третья таблица Данных.

Между первой и второй таблицей связь через ID_Name -> ID_FieldName
Между второй и третьей таблицей связь через ID_FieldName -> ID_FieldData

Единственный минус, придется хранить данные в каком-то общем типе, Variant или String, а приводить к нужному типу на месте.