Всем привет !
-------------
Справочники - Тема актуальная. Хотелось бы знать, кто как реализует в своих проектах хранение справочных данных (плоские таблицы, ОО-представления или что-то среднее).
Конечно на www.ibase.ru по данной теме теория есть , но хотелось бы узнать, что на практике (кто к чему пришёл).
-------------
Конечно, при детальной проработке (если это вообще возможно) предметной области, справочники однозначно можно определить как плоские таблицы. Так проще, конечно-же.
Но меня (я думаю что найдутся и другие) интересует возможность хранения всех справочников в структуре более приближённой к объектной БД.
-------------
В поисках уже изобретённого велосипеда пришёл к структуре (файл Visio в аттаче),
которая в принципе позволяет хранить всё что угодно (более или менее, конечно)
с любыми внутренними ссылками (структура в общем-то стандартная).
(в идеале весь проект можно туда "засунуть")
Но тут-то и проблема - чтобы как-то её реализовать, необходимо ограничить и определить правила.
И тут вопрос уже (как мне кажется) зависит не столько от предметной области проекта, сколько от правил работы в ОО БД вообще.

Есть куча вопросов и ньюансов по её обслуживанию.

Кто желает поучаствовать (ну там обменяться опытом, поругать, предложить что-то иное или посочувствовать) - dendroid-box@yandex.ru (желательно), ну или на форуме.
-------------
З.Ы. Буду рад любому его проявлению (в смысле участия :) ).
З.З.Ы.(есть БД под Interbase, кое-какая литература)
З.З.З.Ы В форуме встречал упоминание о "Идеиях Тенцера"? (если можно ссылку плз.)

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

И снова всем привет !!!
----
Люди, как на счёт внести свою лепту в проектирование структуры ОО БД.
----
Выкладываю следующий вариант схемы "ядра" ОО БД (а-ля А.Тенцер).
Просьба "знатокам" просмотреть схему и вынести "вердикт" :)
(если не трудно, укажите, на что обратить внимание, что можно улучшить)
плз.
----
З.Ы. (а то, понапридумывали сами себе, понимаешь, крутые структуры, там BackOffic'ы всякие :) и радуются :) )
----
З.З.Ы. На самом деле, большое плз. А то одному трудно всё (да и вообще что-то существенное :) ) заметить.

Новая редакция структуры ОО БД (пока всё ещё а-ля А.Тенцер с незначительными изменениями) в формате VSD (Visio)
----
Кстати а сам А.Тенцер где базируется (ну типа домашней страницы или форума ...)

Операция ПЕРЕМЕЩЕНИЯ (в соответствии со схемой ОО БД А.Тенцера)
----------------------------------------------------
В общем случае задача ПЕРЕМЕЩЕНИЯ объекта (например товара со склада в отдел продаж) сводится к операции, в которой "принимают участие" следующие сущности:
---
1. Объект-операция (объект, который логически группирует перемещение; например - накладная на внутреннее перемещение)
2. Объект-хранилище (где в данный момент находится перемещаемый объект)
3. Объект-приёмник (куда требуется выполнить перемещение)
4. Перемещаемый объект/объекты (что именно перемещается)
---
5. История перемещений для объекта-приёмника (в историю добавляется запись об объекте-приёмнике и перемещаемом количестве)
6. Истории перемещений для объекта-хранилища (для объекта-хранилища)
---
5. Состояние объекта (если перемещение объекта или его части изменяет его статус)
------------------------
Остатки здесь определяются, как разность между СУММОЙ поло
------------------------
Возникает вопрос - а что со связями объектов (например "стул - находится на - складе") ?
Должно ли перемещение изменять связи если для перемещений мы используем отдельную таблицу-хранилище ?