Вот некоторые соображения старого человека:
1. Как мы НЕ используем ООП подход.
Когда мы разрабатываем нечто эдакое, от чего распирает от чувства собственного достоинства, то часто (кстати, не от большого ума) становимся рабами своих идей. Тянем и тянем за уши свои разработки - где это надо, и где не надо. Поэтому важно в определённый момент критически взглянуть на прошлый опыт, и отбросить шелуху.
В части ООДБ, вернее похожего подхода, о котором был мой пост - основные идеи были воплощены в разных тестовых околопрограммах лет 5 назад. В то время я работал в другой геологической конторе, занимался программированием, но других задач.
Не скрою, когда работал над нынешним проектом, было горячее желание впихнуть всю эту чухню для хранения основной атрибутики. Но чувства реальности одержали верх. Все таблицы основной атрибутики, в твоей, Lepsik, терминологии - flat.
Это тем более необходимо, что структура таблиц баз часто спускается "сверху", и не редко снабжена уже готовой прогой. Даже если базы делали Московские болваны в министерских службах, переделывать нельзя или нерационально.
Массивы инфы, с которыми нам приходится работать - не маленькие. Инфа - результат работы многих людей. Поэтому основное требование - надёжность и прозрачность (flat здесь очень помогают), исходя из того, что затраты на получение геологической, природопользовательской, природоохраной, экономической и финансовой информации на порядки превышают затраты на создание прикладной проги.
2. Как мы используем ООП подход.
То, что я писал о нашей ~ООБД, мы это используем, но как удобное дополнение к уже эксплуатируемым базам данных, для управления разнородной информацией при помощи единообразных манагеров, смотрелок и т.д. Это для тех специалистов, которые находятся "над" всеми информационными массивами (не только в цифровом представлении, но, например, это может быть каменный материал кернохранилищ, или бумажный отчёт фондов).
Часть атрибутивной (наиболее значимой для оперативного управления) информации из существующих баз сливается в тот самый КО (каталог объектов), о котором я писал. Это приводит к избыточности информационной системы из-за дублирования части инфы основных баз в КО. Но позволяет, грубо говоря, быстро узнать, на какой полке, что находится.
Знаешь на что это похоже? Наверное, самый удачный пример - это база данных контроллера глобального каталога на контроллере домена W2k. Немного ото всюду.
Что оказывается самым трудным - синхронизация инфы в существующих базах с их репликами в каталоге КО. Если есть идеи, как это лучше делать, то давайте обсудим.
PS. Да Ё-МОЁ
! Lepsik, опять вижу дополнение твоего поста, которого, только, что не было. Сисадмин! Ты шо спишь. Просыпайся, попинай свою прогу.
ща забаню нафиг 
