Правильно ли хранить данные JSON в MySql, в место создания кучи таблиц?

Question

[Илья]

Есть пользователи (около 200), и страница Портфолио, на которой отображается 10 таблиц, у всех таблиц разное количество столбцов, строки могут изменять(добавлять/удалять) сами пользователи.
То есть, у каждого пользователя своё портфолио и соответственно свои данные в таблице.
Есть 3 варианта хранения информации:

1. Создать общую таблицу в MySql, которая бы хранила 1 строку с любой таблицы в json формате.
   
2. Создавать под каждую таблицу страницы, таблицу(10шт) в БД MySql, с нужным количеством столбцов
   
3. Создать общую таблицу с максимальным количеством столбцов и где столбцов меньше, оставлять поля пустыми
   

Поиск и сортировка по данным таблиц не нужна, в каком виде правильнее хранить информацию и почему?

Comments

[alex-1917]

Как минимум надо создать две таблицы со связями, тогда не нужен ни json в ячейках (то еще зрелище), ни какие-то там пустые поля

Answer 1

[Barmunk]

Это классическая реляционная структура. Почему это все надо хранить в json?

Comments

[Илья]

То есть вы предлагаете иметь 3 таблицы:

• Пользователи(id(1),логин,пасс)
  
• Таблицы(id(2),id_пользователя(1))
  
• Данные таблиц(id,id_таблицы(2),номер_столбца,текст)
  

Так?

[Barmunk]

Илья, да, через связи "один к одному", "один ко многим", "многие ко многим". Конкретно в вашем случае это "один ко многим". Прочтите про "принципы нормализации базы данных", к примеру addphp.ru/materials/mysql/1_3.php сразу станет понятнее.

[Илья]

Barmunk, но тогда в каждой записи "данных таблицы" (а их получиться около 2000) мне придётся хранить лишнюю информацию:

1. Ид таблцы
   
2. Номер строки
   
3. Номер столбца
   

Получается что лишней информации больше чем нужного текста, таблица будет смотреться громоздкой.
Но пока что это лучшее решение.

[Boris Köln]

придётся хранить лишнюю информацию

Это нормально

[Barmunk]

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

Любая orm, на любом фреймворке умеет это все проставлять налету, записывая только данные и так же извлекать данные из связей.

2000 это не много.

Answer 2

[ThunderCat]

Читать нормальные формы для РБД. Связи. Коротко - таблицы должно содержать отдельные значимые единицы информации в отдельных полях, если эти информационные блоки относятся к разным сущностям - это должны быть разные таблицы. Связи между сущностями соотносятся через ключи-идентификаторы. Дублирование информации в таблицах в идеале отсутствует, то есть если в таблице А есть значение а, которое может быть связано с таблицей Б, в Б это значение не записывается, а создается связь через ключ с таблицей А, или, если таких связей может быть много - создается отдельная таблица связей(один ко многим или многие ко многим).

Answer 3

[Alex XYZ]

Можно, конечно, только тут есть одна проблема - проверка валидности данных перед записью в MySQL. Из коробки в MySQL нет встроенных средств проверки схемы. Я такую проверку писал на Java/JavaScript/Nashorn (чтобы одна и та же функция валидировала JSON на выходе со страницы и на входе в сервлет) перед сохранением.