Вопрос наверное к экспертам в области баз данных

Хочеться реализовать возможность создания типов объектов и их экземпляров, причем информацию о них
хранить естественно в базе (MSSQL).

1. Пользователь создаёт тип.
1.1. Определяет имя типа.
1.2 Определяет набор свойств которыми может обладать тип.
1.2.1 Свйства могут быть как скаларными так и пользовательскими справочниками.
(то есть пользователь может определить соственный справочник, заполнить
его предопределёнными значениями и определить его как свойство типа).

2. Пользователь может создавать объекты заданного типа.

Рассмотрим примет.

1. Пользователь создаёт тип 'Геометрическая фигура'
1.1 Имя типа = 'Геометрическая фигура'
1.2 Определяет набор свойст
Площадь — целочисленный
ВидФигуры — пользовательский справочник
Квадрат
Окружность
Треугольник

2. Пользователь создает объекты.

id Тип Площадь ВидФигуры Объем
1 'Геометрическая фигура' 100 Cсылка на Квадрат ---
2 'Геометрическая фигура' 100 Cсылка на Квадрат ---
3 'Геометрическая фигура' 100 Cсылка на Квадрат ---
4 'Пространственная фигура' --- Cсылка на Шар 10

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

Хотелось бы посмотрить на пример(паттерн) как такое реализуется, догадываюсь, что я далеко не
первый кто столкнулся с подобной задачей.

Заранее благодарен И да прибует с вами сила

Здравствуйте, MrOrbit, Вы писали:
MO>Хочеться реализовать возможность создания типов объектов и их экземпляров, причем информацию о них
MO>хранить естественно в базе (MSSQL).
Microsoft Access.

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

B>Здравствуйте, MrOrbit, Вы писали:
MO>>Хочеться реализовать возможность создания типов объектов и их экземпляров, причем информацию о них
MO>>хранить естественно в базе (MSSQL).
B>Microsoft Access.

Тогда уж лучше посмотреть как это делает внутри себя "1С".
В 7.7 и 8.0 реализовано именно то, что ты хочешь сделать.
(не расстаривайся, но они уже это давно сделали)


Только, если есть возможность, то смотри V8.
Там все внутри сделално горазо лучше.
Так, что если есть возможность посмотри 8.0.
Смотри что снаружи и а что внутри.

Тогда тебе будет проще свой паттерн сделать.

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

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

B>>Здравствуйте, MrOrbit, Вы писали:
MO>>>Хочеться реализовать возможность создания типов объектов и их экземпляров, причем информацию о них
MO>>>хранить естественно в базе (MSSQL).
B>>Microsoft Access.

RB>Тогда уж лучше посмотреть как это делает внутри себя "1С".
RB>В 7.7 и 8.0 реализовано именно то, что ты хочешь сделать.
RB>(не расстаривайся, но они уже это давно сделали)


RB>Только, если есть возможность, то смотри V8.
RB>Там все внутри сделално горазо лучше.
RB>Так, что если есть возможность посмотри 8.0.
RB>Смотри что снаружи и а что внутри.

RB>Тогда тебе будет проще свой паттерн сделать.

Установил я V8. Не знаю я смотрел ли ты внутрь MSSQL базы, но там очень мало информативного.
Мало того, что в базе больше сотни таблиц и нет ни одной связи, так там ещё и данные в бинарном виде представляются.

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


MO>Установил я V8. Не знаю я смотрел ли ты внутрь MSSQL базы, но там очень мало информативного.
MO>Мало того, что в базе больше сотни таблиц и нет ни одной связи, так там ещё и данные в бинарном виде представляются.


БД V8 смотрел где-то около года назад...
Сейчас я другими делами занимаюсь, поэтому подробную консультацию дать трудно.
Формат БД они описывали на каком-то диске ИТС, если найду, то свисту.

Для облегчения тебе нужно сделать Конфигурацию из двух справочников.
И посмотреть — что будет в БД SQL.

Все связи там реализуются программным путем.
А описаны они в метаданных — это специальная иерахическая таблица(-ы).
Если мне не изменяет память, то называлась она config, или что-то в этом роде.

Бинарников пугаться не надо.

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

MO>Хочеться реализовать возможность создания типов объектов и их экземпляров, причем информацию о них
MO>хранить естественно в базе (MSSQL).

MO>1. Пользователь создаёт тип.
MO>...
MO>2. Пользователь может создавать объекты заданного типа.
MO>...
MO>По сути дела, что-то вроде базы в базе.

Сразу советую найти возможность этого не далать. Поддерживать свои метаданные очень сложно и дорого. Особенно если собственно "данных" будет много и требуется производительность.

Обычно делают по стандартной схеме:

[Типы объектов] -- [Атрибуты объектов]
     |                   |
 [Объекты] -- [Значения атрибутов]

Потом начинают навешивать вспом. таблицы, выполняющие роль индексов, и т.д.

W>Сразу советую найти возможность этого не далать. Поддерживать свои метаданные очень сложно и дорого. Особенно W>если собственно "данных" будет много и требуется производительность.

Обычно делают по стандартной схеме:
W>Обычно делают по стандартной схеме:
W>

W>[Типы объектов] -- [Атрибуты объектов]
W>     |                   |
W> [Объекты] -- [Значения атрибутов]
W>

W>Потом начинают навешивать вспом. таблицы, выполняющие роль индексов, и т.д.

Вот вот я пришёл к чему-то очень похожему. Я прекрасно понимаю, что поддерживать и производительно
реализовать подобное решение будет весьма не просто.

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

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

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

Если типов много, то лучше в одной таблице.

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

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

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

W>Если типов много, то лучше в одной таблице.

А если в одной таблицы, тогда сразу же возникает проблема управления метаданными. Со всеми
вытекающими отсюда последствиями.

W>Сразу советую найти возможность этого не далать. Поддерживать свои метаданные очень сложно и дорого.

Чего ж там такого "сложного" и "дорогого"? Самый естественный путь.

W>Обычно делают по стандартной схеме:

Это конечно, проще и дешевле ) Нда... И что потом? Там, где в нормальной базе ты соединял бы два небольших справочника, а тут будешь соединять две копии немерянной таблицы (скажем, миллионов 10 записей для объектов и миллионов 50 для свойств) по сложному условию. Вот радость-то серваку...

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

А можно узнать, в чем собственно "геммор поддержки многих таблиц"? В том, что их нужно нормально размещать по tablespace'ам, нормально индексировать и нормально считать статистику? А для предложенной схемы этого делать не надо, потому что все равно не получится толком.

В общем, имхо, я бы советовал хорошенько подумать, чтобы переходить на предложенную схему хранения "по свойствам". Иногда это выгодно и удобно. А иногда — лучше классическую схему.

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

iT>Это конечно, проще и дешевле ) Нда... И что потом? Там, где в нормальной базе ты соединял бы два небольших справочника, а тут будешь соединять две копии немерянной таблицы (скажем, миллионов 10 записей для объектов и миллионов 50 для свойств) по сложному условию. Вот радость-то серваку...

О низкой эффективности такого подхода я предупредил.
Твои предложения?