Лукойл в отдельно взятой стране решил один раз так сделать.
Но денег дать только за РМ.

Вроде да. Но опять же, это может быть как в анекдоте про Шостаковича ))

Почитал дискуссию. Думаю всё проще. Думаю товарищи из академической среды банально отстали и не знают, как делается современная разработка. То есть думают, что всю интеллектуальную работу выполняют СА, а разработчиков, то есть инженеров нет, но есть кодеры (на фортране). Такие товарищи говорят какие-то непонятные вещи, кажется что они ушли вперёд, а после детального погружения оказывается наоборот, они безнадёжно отстали.

Дба нужен для физической модели данных, хороший системный аналитик должен уметь строить качественые логические модели данных. На проектах где системы работают с тысячами разных таблиц без понимания аналитиком модели данных он не сможет нормально требования формулировать, управлять ожиданиями заказчика. Да банально грамотно юзкейс не описать для такой системы не понимая с какими данными она работает. То что у. вас накипело объясняется, к сожалению по рынку не так много аналитиков которые умеют это делать. В основном это как раз те кто позиционирует себя как системный аналитик.

Логическая и физическая модели будут отличаться...this smells

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

Там не в этом дело, если мы про компетенции аналитиков говорим. Уровень понимания реально крайне низкий, из БА почти никто не умеет рисовать структурные схемы. Из системных больше половины не отвечают на вопрос «как в реляционной базе сделать связь многие ко многим» При этом те же самые люди вменяемо рисуют процессы в разных нотациях. Проблема в том что практически везде разработка организована таким образом что от аналитика не требуется описывать структуру данных, все мыслят поведением либо кейсами либо юзерсторями. Либо требованиями к системе которые про «черный ящик» и вроде бы неправильно требовать то как должно хранится. В итоге аналитикам просто негде научиться этому и выстреливают те кто работал с базами на техподдержке или те кто отчеты пилил в начале карьеры. Если те кто организуют процесс поймут важность работы с моделями данных, то ситуация может выправиться. Будет спрос появится и предложение.

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

Физические же модели подвижны и постоянно меняются, и меняют их разработчики.

Ещё хорошая практика, когда ДБА делают ревью и тюнят DDL, созданные разработчиками.

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

Поэтому логическая модель данных - это атавизм в каком-то смысле.

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

Если у вас модель делает разраб а аналитик ревьюит, то знания по команде распространяются и все ок. У нас немного другой подход в обратную сторону - доменную модель делает системный аналитик в специальном инструменте (набивает состав объектов и связи), а разработчик потом её докручивает. Это избавляет разработчика от лишней работы. Предварительно структуру данных согласуем вместе на картинках простых. Просто при вашем подходе прежде чем разработчик сделает модель он должен откуда-то узнать всю информацию для её создания. То есть аналитик как минимум один раз уже опишет это все.

Логическая модель чего?

В моём понимании, есть модель домена (агрегаты, сущности и т.п), и есть БД, которая реализует служебный аспект - персистентное хранение данных.

В общем сделали таблицу на сто полей. Поля назвали field_0, field_1,.... И аналитики (судя по оставшимся артефактам) составили логическую модель как разложение нескольких моделей на часть колонок этой таблицы и в первом поле был идентификатор типа модели.

В коде был маппинг на эту одну таблицу нескольких классов.

Для модели "счёт клиента" в первой колонке был идентификатор "1" и заполнялись колонки от field_0 до field_17.

И так было порядка двадцати моделей в этой таблице.

Да это боль. Но думаю тут проблема не в аналитиках )

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

И прочие забавы работы с такой схемой

Мое дело было провести ревизию, показать слабые места, дать рекомендации по оптимизации (первая жалоба на перформанс была)

Я где-то описывал мой подход?

Аналитики каждый раз договариваются с разработчиками об артефактах аналитики и их гранулярности.

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

«ваш подход» в смысле «описанный вами» в сообщении после «еще хорошая практика». Почему нельзя назвать эти структуры логической моделью даных? Если один из артефактов аналитики это «описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы» то его вполне можно назвать и так. Часто еще делают схемы предметных областей или что-то такое. Но это более вольные диаграммы и на них часто много лишнего.

В конечном счёте за консистентность и производительность отвечают инженеры (разработчики, DBA, DevOps).

Поэтому схемы баз данных, а у каждого модуля/микросервиса может быть своя схема/база, проектируют инженеры.

Если это делают аналитики, то всё будет очень плохо в итоге.