Буквально вчера сделал табличку Contact где поле name это json.
В зависимости от значения в поле legal_form там либо 3 поля для ФИО либо name и full_name организации

Ну вот у меня кейс: хранение информации о событии. Разные события - разные поля/данные, а сами события в одной таблице. Сначало было - под каждую новое поле - новый столбец ( куча nullable). Выглядит не очень. Сделал что бы поля хранились в one to many типа eav. Но по запросам выходит не очень. Json прям кажется идеально бы лёг, но надо помнить структуру каждого события (какие поля). И что делать если какое то событие изменится по структуре (набору полей) - не совсем понятно. Хотя возможно надумваю лишние проблемы, которых не будет.

ну это своего рода логи

конфиги мб какие хранить или логи

Есть почти такой же кейс, без json) а в чем профит, почти же нет динамики. Или там doctrine type конвертация?

а чем VO тебе не люб?

Причём тут динамика, в разных кейсах там разная структура. Как это сделать иначе?

Причём тут VO то?

Доктрину я выкинул

Ну а чем json отличался бы от отдельных колонок?

Так же брать из разных проперти в завимсости от кейсе и legal form

Хотя если завернуть в полиморфизм и разные классы, то да - красиво

ну по сути у тебя username, где может быть либо ФИО, а может ФИ,  или Organization, а где-то не помню где ИО

Профит то в чём? Избежали использования json'a?)

Ну вот у нас примерно так и есть

Никакого, как и обратного профита

Тут конечно надо сами кейсы смотреть, ради которых намучено

Мне пока не понятны

Намучено это делать колонки которые не используешь в определённых кейсах, зачем сложил всё в одну таблицу, если схема разная у записей? У меня вот схема одна, а детали упакованы рядом

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