Таблица с JSON полем или несколько таблиц под каждый тип данных, какой вариант проектрирования выбрать?

Question

[Константин Толмачев]

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

Если делать в варианте один параметр одна строка в соответствующей таблице, то в ряде таблиц на время приема может быть до 20-30 млн записей. Если же все это делать в варианте json поля, то возникает вопрос скорости, и маскимального количества полей которые могут поместиться в это самое поле. Ибо может в любой момент возникнуть необходимость добавить еще какие то поля, по требованию законодательства или администрации.

Кто проектировал базы с динамическим количеством полей разных типов, как вы решали данную задачу? Ну и конечно если есть хорошие статьи на эту тему, буду рад почитать.

Comments

[sim3x]

Когда именно появляется динамичность в анкете?

Answer 1

[JhaoDa]

В JSON может поместиться всё, что вы захотите в него поместить, mysql не волнует, сколько там «полей».

Размер JSON-поля определяется переменной max_allowed_packet.

Ну и лучше юзать PostgreSQL, там с JSON'ом всё лучше (в JSONB-варианте) — например, нормальные индексы.

Comments

[Константин Толмачев]

А по скорости поиска что будет "эффективнее" Json или множество таблиц по связи один ко многим? И есть ли вообще какая то разница?

Сейчас все поднято на mysql, но PostgreSQL в принципе можно рассмотреть. Спасибо

[JhaoDa]

Константин Толмачев, что вы подразумеваете по поиском? Выборка из БД или FTS?

[Константин Толмачев]

JhaoDa, Выборка из БД

[JhaoDa]

Константин Толмачев, ну откуда ж я знаю, как у вас получится, не зная, что вы там хотите сделать? Могу только сказать, что JSONB + индексы это вполне шустро. Пробуйте, тестируйте.

[Константин Толмачев]

JhaoDa, Спасибо за ответ.

[ThunderCat]

JhaoDa, Константин Толмачев
во первых https://dev.mysql.com/doc/refman/8.0/en/json.html , в мускуле все давно есть, не надо всем тыкать постгрес при рабочем мускуле
во вторых - связка группы таблиц будет сравнима/быстрее по скорости выборки + иметь более четкую и наглядную структуру.
И в целом - JSON хранение в базе подразумевает хранение рандомного количества рандомных нестрого связанных данных, тут же задача стоит немного иная - хранение хоть и большого, но четко стандартизированного количества значений со связями через отношения.

[JhaoDa]

ThunderCat, я и не утверждаю, что всё надо переделать на JSON/PostgreSQL. Вопрос задан, я ответил — да, можно юзать; да, скорость вполне приличная, но это дело субъективное.

в мускуле все давно есть

что «всё»? Есть индексы без генерируемых значений?

[ThunderCat]

Есть индексы без генерируемых значений?

не совсем понимаю смысл фразы. Можно для тупых нефанатов постгри? Или оно на инглише как то более осмысленно звучит?
https://dev.mysql.com/doc/refman/8.0/en/create-tab...

[JhaoDa]

ThunderCat, g INT GENERATED ALWAYS AS (c->"$.id")),. PG может индекировать JSONB весь и сразу, а mysql'ю надо создавать набор данных для индексации.

[ThunderCat]

JhaoDa, получается надо производить генерацию индекса после добавления всех используемых данных?

[Константин Толмачев]

ThunderCat, т.е. я правильно понял, что вариант через таблицы будет быстрее? и выбирать данные будет проще?

[JhaoDa]

Константин Толмачев, ну конечно же он будет быстрее, что за странный вопрос? Но вы, мне кажется, возводите скорость в какой-то абсолют. Скорость работы сервиса можно менять на скорость его разработки, равно как и наоборот.

Вот выборка за 0,05 секунды это быстро? А 0,08? А если 0,2 секунды, при том, что весь ответ сервера генерируется 2 секунды?
EXPLAIN в руки и сравниваем реальные результаты.

Answer 2

[Дмитрий Энтелис]

Зачем изобретать велосипед?
Есть форма на 120 полей - сделайте 120 полей в таблице.
1 анкета - одна строчка.
Удобно выбирать, удобно фильтровать.

Comments

[Константин Толмачев]

Вопрос в том, что полей сейчас 120, далее может быть больше, и нужно, чтобы поля добавились, динамически, т.е. без редактирования структуры базы данных, и без участия разработчика. Т.е. нужно поле, в админке добавили и забыли о проблеме. Так что вариант "Есть форма на 120 полей - сделайте 120 полей в таблице." не возможен в данном конкретном случае.