Как спроектировать БД с переменным количеством параметров?

Question

[Mamol27]

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

Comments

[Артём Токаревских]

Вполне хорошее решение, если все параметры одного типа

[Mamol27]

каким запросом можно будет собрать таблицу или запросить данные как отображено в таблице под схемой БД?

[Виталий Хоменко]

Понимать бы еще какую задачу должен выполнять функционал.

Answer 1

[D SH]

Есть два пути:

• Использовать JSON, и столбец params, в который загонять все эти параметры, например {"param_1":"value_1", "param_999":"value_999"}
  
  
• Создать еще одну таблицу с полями: id, person_id, name, value, где person_id - id из таблицы person, name - название параметра, value - значение
  

,

Comments

[Mamol27]

то есть убрать табличку "params" и перенести поле "name" в табличку "data"?

[Ihor Gevorkyan]

Mamol27, не нужно этого делать. Иначе, не получите результат, который показывали. А параметры, в итоге, будут одинаковые для всех записей? Я имею в виду "param_n", где "n" - это одинаковое значение для всех строк в результирующей таблице?

[D SH]

Ihor Gevorkyan, тут скорее нужно смотреть на загруженность уже, если запросов будет не очень много, то можно использовать вариант со второй таблицей, так как это позволит создавать кастомные переменные, для каждого пользователя, вариантов много)

[D SH]

Mamol27, совершенно верно)

[Mamol27]

Ihor Gevorkyan, должен быть один набор параметров для всех пользователей. При этом этот набор может редактироваться: какие-то параметры убираться, какие-то добавляться.

[D SH]

Mamol27, ну вот, если у вас нет проблем с большим количеством пользователей, можете использовать вторую таблицу

Answer 2

[cicatrix]

На одних RDBMS свет клином не сошёлся. Посмотрите в сторону nosql, мне кажется, вам это больше подойдёт.

Answer 3

[Дмитрий]

Я рекомендую посмотреть в сторону EAV. Но!!! Смотреть очень внимательно. Там есть очень большая куча плюшек и примерно такая же куча ....хм.... не плюшек. Выбирать только вам.
И добавлю сюда ссылку на очень похожее обсуждение:
Как хранить абстрактные модели данных в реляционных БД?

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