Хочется организовать структуру данных с нефиксированым набором атрибутов.
Есть какой-то объект в таблице, хотелось бы с ним связать любое количество параметров(атрибутов) и чтобы значения данного атрибута были типизированы - т.е. сохранялись возможности для поиска, вывода в отсортированом виде и т.д. Своего рода 3D-модель (обьект-атрибут-значение атрибута)

Проще говоря я хочу иметь возможность модифицировать не только значения отдельных полей, но и добавлять/удалять поля - это должна быть штатная операция. Этого можно сделать к примеру если использовать ALTER TABLE ... ADD/DELETE COLUMN ... Но это не совсем удачное решение.

Есть ли для этого какие-то готовые решения?

> Ну и храните в "Своего рода 3D-модель (обьект-атрибут-значение атрибута)" виде. Выбрать можно всегда, а после уж сортируйте как хотите.

неее, своими силами сортировку проводить не хочется совсем....
будет 100000 значений - все придётся выбирать чтобы вывести с 25 по 50


> Для таких задач подходят СУБД Pick, UniVerse, JBase.
Честно говоря я не сомневаюсь, что решений масса есть, но всё-таки хочется ориентироваться на обычные реляционные БД. Как-то же это должно решаться.

> или совсем развернуть вдоль (дополнительная таблица Values (id, TableID, RecordID, FieldName, FieldValue)),
Вот это уже ближе.Я вот собственно к такой схеме и склоняюсь.

Только скорее так:
Records (Id, AttributeSetId)
AttributeSets (Id)
Fields (Id, AttrubuteSetId, FieldName, FieldType (int)) -- Таблица атрибутов
ValueType1 (FieldId, RecordId, FieldValue(int)) -- Таблица целочисленых значений
ValueType2 (FieldId, RecordId, FieldValue(text)) -- Таблица тестовых значений
....
И так для всех типов, будет немного.
В данном случае каждая запись в Record имеет набор атрибутов - это одно измерение.
Чтобы выцепить список - мы сперва выбираем список атрибутов.
Дальше мы выцепляем по этому набору ОДНИМ запросом с использованием OUTER JOIN прям табичку, в которой будут все значения всех атрибутов и тут же можно осуществлять сортировку, фильтрацию. Проверено - работает.
На мой взгляд если число атрибутов относительно невелико (ну до 10 например) - так жить можно.

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


> или наделать в основной таблице кучу полей Int1, Int2, String1, String2 (смысл им придавать у каждой записи свой, хранить соответствие в каком-нибудь справочнике).
Ну тоже вариант, только куча всё равно получится ограниченой.
Возможно комбинирование вариантов 1 и 2 - те наделать в Records 3-4 поля каждого типа (ну или в соответствии с частотой использования) и использовать "статические" и "динамические" поля совместно. Причём статические также включать в описание. Тогда динамические поля будут использованы нечасто, в результате производительность не будет страдать сильно...

>Если невелико, то действительно можно. Но я наблюдал систему построенную по такому принципу и поначалу там
> число таких атрибутов действительно было невелико, но относительная простота добавления нового атрибута
> сильно развращает программистов.
Естественно реь идёт о "поисковых" атрибутах. Но пока мне симпатизирует комбинированое решение - когда часть атрибутов фиксируются в самой таблице, только переназначается их смысл. Причём если кол-во динамических атрибутов вырастет - мы можем увеличить кол-во статических посредством ALTER TABLE (сделать это руками) и перенести часть динамических атрибутов в статические.

>поискрулит.
да, если знаешь ключевые слова. Так что за EAV спасибо, собственно что я и хотел.

> мягко говоря - странный подход. Или используйте СУБД, которые предназначены для хранения подобных структур или меняйте структуру, т.е. сделайте "обычные реляционные данные".
Тут проблема вот в чём - таблица Records (условно) для которой необходимо найти решение по добавлению атрибутов - малая часть НОРМАЛЬНОЙ РЕЛЯЦИОННОЙ БД, в которой таких проблем нет и всё прекрасно укладывается в списочно-ссылочный формат. Стоит ли ради того чтобы красиво решить эту проблему привлекать специальные средства?
Ещё момент - в этом случае БД требуется под ОС Linux и желатеьно свободная.