Нормально ли хранить json в MySql?

Question

[buryakov_dima]

Здравствуйте. Работаю над веб-сайтом и на сайте есть функция регистрации пользователей, при регистрации указывается стандартно email,login,pass, но по мимо этого указываются ещё много различных данных - ФИО,возраст,страна,город,телефон и т.д. Стоит ли эти данные (фио,возраст,страна и т.д) хранить в БД в формате JSON или нет? p.s в дальнейшем по этим данным будет производится сортировка.

Answer 1

[Finnish]

Теория
Реляционные базы подразумевают, что все часто используемые поля должны храниться в отдельных столбцах. В какой-то момент Вам понадобится искать/сортировать по городу, а его хранение внутри JSON сделает эту операцию крайне сложной.
Все преимущества JSON-а сводятся к тому, что в одной записи можно "легко" добавить или удалить какое-то поле, не прибегая к модификации таблицы. Лёгкость написана в кавычках потому, что модификация одного поля выполняется сложнее, чем первоначальная запись всего объекта: взять JSON; преобразовать в объект; модифицировать значение нужного поля; преобразовать в строку; записать её в базу данных. И делать это нужно будет средствами приложения, MySQL на это просто не способен.

Практика
Использование JSON является нормальной практикой. Если возникает необходимость выполнять поиск по какому-то полю, оно выносится в отдельную колонку. Работы по переносу рутинные, но требуют внимательности от программиста, т.к. путь до значения изменился. Например, раньше было user.data.city и стало user.city.

Сейчас набирает популярность PostgreSQL, где работа с JSON выведена на уровень SQL-синтаксиса. Там Вы сможете легко добавлять/модифицировать/удалять отдельные JSON-поля, не прибегая к помощи приложения. Даже индексы поддерживаются!..

Comments

[Александр Прозоров]

Стоит добавить, что описанный вами тип данных называется jsonb и доступен с версии Postgre 9.4

[Finnish]

Александр Прозоров: Был на Highload 2014, где наши ребята хвалились новым индексом, названным VODKA. Название, конечно, позабавило, но прирост скорости по сравнению с предыдущими реализациями дало надежду, что скоро у MongoDB появится очень интересный конкурент.

[Александр Прозоров]

Finnish: На конференции в Новосибирске, в прошлом году они прямо противопоставляли новый движок MongoDB.

Answer 2

[Александр Кондауров]

Постановка вопроса интересная - Нормально ли блаблабла.
Сделайте сначала как думаете, храните динамичные поля в json поле строки таблицы. Потом когда задолбает писать sql запросы по извлечению этих полей вы сами поймете что нужно где хранить. Нормально то что решает конкретно ваши проблемы.

Postgresql умеет работать с json, но приходится писать десериалайзеры и сериалайзеры этих полей при сохранении и извлечении. Мне это не нравится, дополнительный код.
Посмотрите для интереса что умеет делать Mongo. Сейчас меня будут критиковать, типа человек работает с релиационными бд, но если вы не знакомы с ней то я считаю это будет полезной информацией

Answer 3

[Roman K]

p.s в дальнейшем по этим данным будет производится сортировка.

Если будет JSON - нет, не будет.
Или берите Postgres.

Answer 4

[Руслан Федосеев]

json будет храниться в виде одной строки. И чтобы отсортировать по городу - надо будет как-то извлечь значение из этой строки. Я бы на вашем месте не усложнял себе жизнь, а хранил отдельными полями. В дальнейшем работать с этим вы сможете обычными sql командами...

Answer 5

[sim3x]

нет
лучше в постгрес

Answer 6

[Пума Тайланд]

а как вы собираетесь их сортировать если у вас они json ?
логично что надо хранить нативно