ViPRosа так согасен, что кроме 0,1 нифига не надо
когда то прямо в регистры вводил команды

ViPRosвозьмем контексты
контексты подстравивают макротип, тип, классификатор (т.е. создает их проекции)
не нашел аналогов
возьмем Роль типов, Контекстные роли и т.д.
Роль типа в таблице независимо от имени атрибута определяет в качестве чего эта ссылка тут торчит, т.е. пофиг как он в таблице называется, ты всегда знаешь, что это "Сотрудник", а та "Организация"
контекстные роли свосйств перепределяет поведение интепретатора
я не видел никаких аналогов (помню были зачатки в интербейзе - типа цвет на экране и т.д.)

мне пофиг арность и т.д. связей
мне важно КТО от КОГО зависит, т.е. кто является корянми графа отношений, а кто производные зависимые
потому уменя есть нисходящие и восходящие связи
и т.д.
слушай я воще то 35 лет пишу проги

ViPRosArhat109,

ок
давай возьмем просто макротип и найдем ему аналог в инфорсхеме любого СУБД
я не нашел (есть схема, но у нее узкий функционал (во всяком случае в МСКЛ), таблица может войти ТОЛЬКО В ОДНУ схему)
а макротипы пересекаются
в схему фиг добавишь форинкеи выборочно, а в макротипы можно
т.е. схема не дает адекватного подграфа всей схемы

давай возьмем классификатор
классификатор определяет динамический юнион/проекцию для таблиц
можно использовать вью, но вью имеет мыльен ограничений, а классифиатор нет

макротип - ассоциация таблиц в РМД
классификатор - объединение/проекция таблиц в РМД
их аналогов там нет

Да, интересное было время, можем повспоминать на досуге.
Нисколько не сомневаюсь в вашем профессионализме. 35лет - не пропьешь и видны невороруженным глазом. Равно как и в полезности сделанного в ВИПРОС. Думаю востребовано и активно юзается в корпорации. Даже подозреваю что делалось не в одиночку.

Года два назад, тоже парился "чё всё так плохо в нашей СРМ... тут поле fid там F_Ident, а в data_definition почему-то m_company_id"... а нельзя ли как-то унифицировать? Ввести надтабличку "назначение/смысел полей" и через неё маппить весь код... слава Богу одумался.

Сейчас, есть базовый класс на ПХП "БазоваяМодельДанныхБД", который суть интерфейс, от которого тупо наследуются классы, обслуживающие конкретные таблицы, подставляющие в него как название адаптера подключения (разовый/постоянный), так и названия таблицы, полей, их типа и ОЦ. А также, через него делается контроль доступа, изменение состояния записей, логирование действий юзверя, сращивание паттернов "Таблица", "АктивРекорд"
... А Модели БЛ - теперича, работают тока через этот маппинг классов, формируя километровые запросы - гарантированно верно и "как вздумается", соединяя порой по 20-30 таблиц и отдавая на сервак по 70 строк кода по 80 симоволов... и ничего не знают и знать не хотят о структуре данных в БД. И пишется это достаточно просто:




... а БД как была чистой РМД... так теперь и осталась. :)

Всё решается и разводится классами моделей БД и КОНСТАНТАМИ (на крайняк - статическими массивами) в них, на уровне ЯП.
Не, конечно, каждый модуль теперь имеет дурацкий класс МодульКонфиг, который содержит перечень моделей, урлов, и прочую лабуду (в т.ч. даже свой readme.php), phpdoc, и многа других комментов (суммарно больше половины кода), чего отсутствовало ещё год назад ваще как понятие... :)

... я так подробно только к тому, что а надо ли иметь целый слой маппинга над РМД (терять в скорости, объеме, функциональности и т.д.), если всё это нормально должно выносится в ЯП, который (при желании) даже всё это верно откомпиляет и с оптимизирует... (не ПХП конешно)?
... да, потребуется определенная культура в работе... но ведь вы не едите на горшке, я так догадываюсь... :)

ViPRos,

интересно чем обоснована такая принципиальность?

имхо, РМД - это большой универсальный потоковый комбайн для обработки И хранения данных. Семантика данных - не есть задача РМД, а стало быть обязана выноситься в Приложение на ЯП. Загонять элементы семантики в РМД - конечно можно, но мне кажется, что НЕ нужно... потому как каждый инструмент пригоден для своих задач.

В целом, Вы практически подтверждаете мой тезис: основным критерием разработки ВИПРОС - были хотелки ТАК сделать и только. Никаких МД - там не требовалось по задаче.

Собственно это же подтверждает и _мод последним постом. "Зачем - вопрос не стоит ... надо (читать - хачу)". :)

ViPRos, :)

Да, понятно всё это! И причины и исходные задачи и результат. Я же про другое спросил... решений как обычно - туева хуча... меня заинтересовало Ваше "принципиально...". Вот два крайних подхода:

1. Всё лепить в БД и хранимки... вынося наружу псевдо язык, метаописания и т.д.
2. Всё лепить в ЯП, оставляя в БД тока таблички... никаких макротипов. Внутреннюю структуру БД надо оставлять максимально простой (3-5НФ). "все в сад", пардон в ЯП.

Вы, похоже сторонник первого, я - второго подходов. Свою точку зрения - я попробовал объяснить... мне интересна ваша. Тока и всего. :)

P.S. мне уже понятно, что задачи, которые в реальности требуют моделирования на уровне М0..М5 (то есть которые плохо решаются силами РМД ваще) - это другой класс задач, и помощи тут, мне искать не стоит... ну так, хоть "общие" вопросы обсудить...

ViPRos,

Ну вот да, наверное до меня плохо доходит... теперь понятно. :)