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

Как считаете, какой из подходов создания структуры реляционной БД в данном случае
наиболее разумен:
1) Каждый класс — своя таблицы, изменение структуры — альтеринг таблицы, история изменения таблицы — заведение новой таблицы и переименование старой в ТАБЛИЦА_ДАТАИЗЕНЕНИЯ
2) Таблицы "Класс", "Атрибут", "Объект", "Значение атрибутов". С историей все понятно.
3) Нечто промежуточное:
Таблицы "КлассA", "АтрибутA", "ОбъектA", "Значение атрибутовA"
"КлассB", "АтрибутB", "ОбъектB", "Значение атрибутовB"
и т.д.

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



Еще интересно существуют ли какие-либо open-source-ные прослойки для создания подобных систем

Сергей Герасимов

Здравствуйте, sergunok, Вы писали:

S>В разрабатываемой системе структура данных (классы, их атрибуты, наследование) может изменяться пользователями системы. Кроме этого разумеется могут изменяться значения атрибутов экземпляров классов
S>...
Возможно будет полезна эта статья

Здравствуйте, sergunok, Вы писали:

S>В разрабатываемой системе структура данных (классы, их атрибуты, наследование) может изменяться пользователями системы. Кроме этого разумеется могут изменяться значения атрибутов экземпляров классов
S>Должна поддерживаться история изменения структуры и экземпляров.

S>Как считаете, какой из подходов создания структуры реляционной БД в данном случае
S>наиболее разумен:
S>1) Каждый класс — своя таблицы, изменение структуры — альтеринг таблицы, история изменения таблицы — заведение новой таблицы и переименование старой в ТАБЛИЦА_ДАТАИЗЕНЕНИЯ
S>2) Таблицы "Класс", "Атрибут", "Объект", "Значение атрибутов". С историей все понятно.
S>3) Нечто промежуточное:
S> Таблицы "КлассA", "АтрибутA", "ОбъектA", "Значение атрибутовA"
S> "КлассB", "АтрибутB", "ОбъектB", "Значение атрибутовB"
S> и т.д.

S>Атрибутами могут быть другие классы.
S>Атрибутами могут быть формулы, ссылающиеся на значения атрибутов экземпляров любых классы.



S>Еще интересно существуют ли какие-либо open-source-ные прослойки для создания подобных систем

S>Сергей Герасимов

А еще лучше (на мой взгляд на много лучше) в такой задаче использовать объектную СУБД.
Например, Versant FastObjects .NET .
Или, что все-таки будет менее удобно, опереться на ORM-инструментарий Versant Open Acces .NET, работающий с разными РСУБД.

Из open source инструментов такого рода наиболее известен nHibernate.
Также есть разные инструменты для платформы Java.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Здравствуйте, sergunok, Вы писали:

S>>В разрабатываемой системе структура данных (классы, их атрибуты, наследование) может изменяться пользователями системы. Кроме этого разумеется могут изменяться значения атрибутов экземпляров классов

AR>Из open source инструментов такого рода наиболее известен nHibernate.
AR>Также есть разные инструменты для платформы Java.

ORM не решает проблему изменения структуры данных пользователем системы без перекомпиляции (если я правильно понял термин "пользователь"). Для обеспечения такой функциональности придется вводить свою систему метаданных, В вашей терминологии это скорее всего развитие варианта №2

Здравствуйте, VladiCh, Вы писали:

VC>...

"замучаетесь пыль глотать ..." (с) В.В. П.

Посмотрите Versant Object Database. Более гибкого средства, позволяющего динамически менять структуру хранимых данных, обеспечивать доступ к ним из приложений без перекомпиляции оных и отслеживать их изменение (хранить предыдущие версии) не существует в природе. Вы, конечно, можете пойти по пути (2) или, что очевидно несколько легче (3) вашей классификации, но столкнетесь с массой проблем, решать которые будете очень долго.

Ответ 2.

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Здравствуйте, VladiCh, Вы писали:

VC>>...

AR>"замучаетесь пыль глотать ..." (с) В.В. П.

AR>Посмотрите Versant Object Database. Более гибкого средства, позволяющего динамически менять структуру хранимых данных, обеспечивать доступ к ним из приложений без перекомпиляции оных и отслеживать их изменение (хранить предыдущие версии) не существует в природе. Вы, конечно, можете пойти по пути (2) или, что очевидно несколько легче (3) вашей классификации, но столкнетесь с массой проблем, решать которые будете очень долго.

Да, но только используя JVI (Java API Versant VDS — теперь Versant Object Database) . Другие API Versant Object Database делать этого не позволяют .

Здравствуйте, Alexey Rovdo, Вы писали:

AR>Здравствуйте, VladiCh, Вы писали:

AR>Посмотрите Versant Object Database. Более гибкого средства, позволяющего динамически менять структуру хранимых данных, обеспечивать доступ к ним из приложений без перекомпиляции оных и отслеживать их изменение (хранить предыдущие версии) не существует в природе. Вы, конечно, можете пойти по пути (2) или, что очевидно несколько легче (3) вашей классификации, но столкнетесь с массой проблем, решать которые будете очень долго.

Возможно, рекламируемый здесь Versant Object Database — хороший вариант, не работал с ним. Просто не всегда есть возможность перескочить на другую базу данных. Это связано точно так же с массой проблем, по большей части организационных и финансовых . А ORM средства для данной задачи слабо подходят.

Здравствуйте, sergunok, Вы писали:

S>2) Таблицы "Класс", "Атрибут", "Объект", "Значение атрибутов". С историей все понятно.

попробуйте посмотреть Firebird3 (они собирались сливаться с вулканом).
в сущности вы строите еще один свой слой метаданных. в вулкане, как я понял, предоставлен доступ на этот уровень.