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

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

Выстроить процесс. Кто чего делает и что кому передаёт.

+1
у меня есть мнение что структура БД это епархия разработчиков.
Работа аналитика это формализация прикладной задачи на натуральном языке, проще говоря
он должен корректно объяснить разработчику что он должен сделать (функциональные требования) и какие есть ограничения к реализации (нефункциональные требования) а также почему он должен это сделать.

А из разработки игр есть здесь коллеги?
Раньше у них и в маркетинге была большая тема digital assets management.

Аналогия к тому, что если что-то можно положить в условный Git (вообще vcs) -- то это стоит сделать обычно.
А если ещё и в чистом тексте можно выразить, как в случае SQL DDL -- это вообще счастье, будут человеко-читаемые diff'ы..

Вопрос "что" может иметь разную степень детализации)) у нас в продукте очень много логики на sql. И она может быть очень сложная. И разработчики не всегда ее знают. Особенно новые или аутсорсеры. Поэтому постановки (которые им, как ни странно, нравятся), содержат детальное описание, что из каких таблиц брать и какие таблицы новые надо создать (как называется, в какую бд класть, какие поля с какими типами данных...)

С опытными разрабами то же самое, только с ними идёт обсуждение, какую структуру надо запилить. Они одобряют постановку в этой части.

- верно

- чтобы не весь документ читать разработчикам (документ занимает 100 стр), а только дельту.

О_о что ж в этом документе-то?

Меня бы за такое побили 🤣

- цель быстро узнать что изменилось в постановке

например, какие поля добавить, удалить и т.д.

Имхо, это очень огромный документ. Очень. Это не постановка, это описание какого-то функционала. А постановка - это ничего лишнего, кроме того, что надо разрабу.

видимо по диффам этого функционала и ставится задача

А как сложился такой стандарт постановки? Интересно, в чем его ценность. И почему бы не сделать дифф отдельно как приложение?

Но это для аналитика работа, имхо

А зачем вам документ в 100 странц для хранения всех постановок? может проще сделать какую-нить иерархию сценариев и уже на этом уровне отслеживать изменения?

Так это по крайнй мере управляемо на уровне элементарных функций, что обычно и требуется при оценке изменений. И можно соответственно рассматривать разные версии этих самых элементарных постановок.

Ну или там RFC, или CR... как вы их там называете)