это нужно базу иметь которая умеет работать с json внутри поля
не все так умеют

Даже sqlite умеет на примитивном уровне. А у тебя мускуль?

eav для настроек тоже так себе идея )

Или ты делаешь фреймворк и "надо много баз супортить"?

Ну вдруг у него мускуль старой версии... Я даже и не помню с какой json появился, вроде с 5.4

Ну тоесть обычно могут бояться jsonb ибо "нет схемы и непонятно как работать" но в eav ровно тоже

не то чтобы фреймворк, но "много баз саппортить" присутствует

Короч для хранения json можно хоть в text хранить. База в этом смысле не важна. Для выборок можно организовать проекции. Тут вопрос что это за настройки такие

я рассматриваю разные варианты хранения настроек, пока собираю информцию по EAV - это еще не окончательное решение

настройки пользовательские из 3d-party сервисов, там может быть что угодно, по сути

согласен, только если хранить в тексте, то напрямую в базе уже ничего не отфилььтровать, только на уровне приложения, что тоже минус

У меня для этого есть тупой key-value сторадж поверх базы где настройки через symfony/serializer хэндлятся (+ аудит). Хранится все в одной табличке (ключ, версия, значение, метаданные). И все отлично. Если мне вдруг понадобится фильтрация скорее всего буду держать отдельную табличку которая будет обновляться по успешному изменению значения.

С eav проблемы с выборками и индексами ровно те же

т.е грубо говоря у вас там
SymfonySerializer->toJson|fromJson ? и все это дело хранится в тексте в базе ?
а в сущности или куда там надо подгружаете через отдельный тип под доктрину ?(если говорить в терминах доктрины, может у вас что другое там)

и что значит + аудит ?
в том плане что налету сверяетесь со схемой настроек ? или отдельной командой раз в Н минут проходите по данным и смотрите все ли ок ?

вот тут важно оговорить что такое "настройки".

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

ну вот типа да, можно сделать отдельную сущность вида UserSettings - пока не принципиально
над этим еще не думалось

аудит это кто когда и что менял. То есть дергаешь ты $settings->save($mySettings, 'some-key') и оно внутри грузит текущую ревизию, проверяет поменялось ли чего, если поменялось - можно создать новую ревизию и записать в базу. Если кто-то успел до тебя записать зафэйлится из-за конфликта по версии. Ну и в базе все ревизии для всех ключей + кто и когда их делал

ну вот я от этого ухожу потому что UserSettings это просто свалка, мне проще хранить отдельные по смыслу настройки по ключу userId

у меня сегодня таблички типа user_settings в себе содержат под сотню колонок

ага, когда эти настройки можно стандартизировать, тогда проще даже расширить хранилище до 100500 колонок