0 [вступление] )
Я не знаю почему но мне найблоьше нравится 3 вариант, но уже надоело делать под себя. хочется сделать как у людей)
не вполне верная стратегия для разработчика. Надо посмотреть как у людей, почувствовать что вы поняли и вам понравилось, а потом сделать также под себя. В рамках этого вопроса лучше вас никто не скажет, как вам надо.
Теперь по делу:
1) вариант подходящий для случая до 5-6 настроек на юзера, и с уверенностью, что их количество расти не будет; если больше - не стоит;
2) это EAV. Не особо вижу в нем смысле, если вам доступен пункт 3;
3) json-колонка settings вполне себе ничего. Важным премуществом является то, что вы тогда можете хранить только переопределенные пользователем значения. А как правило, пользователи не меняют более 20% настроек, особенно если они удачно подобраны. Т.е. после создания у вас будет пустой объект json, и после каждой смены настройки в объект будет добавляться поле, если настройка еще не менялась, либо обновляться, либо удаляться, если юзер нажал "reset to defaults". В случае пункта 1 вам бы пришлось использовать NULL для пометки того, что пользователь не устанавливал эту настройку;
4) не вижу особого смысла: файлы настроек, вероятно, будут небольшими, плюс эти файлы будут лежать у вас списком, а не иерархией, а тогда смысл использовать ФС;
и еще 5) если проект большой и настроек и юзеров много, я бы подумал об использовании документной БД для этой цели - тогда можно будет выделить отдельный сервис для задачи хранения настроек.
