Хранение JSON в реляционных БД?

Как вы думаете это номальная практика хранить некоторые данные в БД (Mysql) в виде JSON строк? Вот например: У нас есть 1000 постов которые имеют фотки (10 штук к каждому) и например комментарии. И нам нужно выводить в цикле посты (штук 20) в таком формате: Пост с фотками и последними 3-мя комментариями. Например как выводятся посты на стене ВК. Можно ли в таблице с постами сделать 2 дополнительных ячейки (photos и comments) и в них хранить данные в виде JSON строк. Там для фоток JSON строка и такойже для 3-х последних комментариев. Ну а при изменении или добавлении фотки или коммента например обновлять эти поля?
Как мне кажется это сильно снизит нагрузку на БД, вы как думаете?
  • Вопрос задан
  • 18682 просмотра
Пригласить эксперта
Ответы на вопрос 6
@myLizzarD
PHP developer
Есть смысл иногда хранить JSON в некоторых ситуациях, но таким случаем очень мало.
А вдруг вы захотите сделать позже поиск по комментариям, или по фотографиям. Что будете делать?
В вашем случай однозначно необходимо разделить все это в разные таблицы. Сделать 1 дополнительный запрос по ключу( вытянуть фотографии) - это и нагрузкой то не назовешь для бд.
То же самое и с комментариями.
Ответ написан
fornit1917
@fornit1917
Если вам не надо по полям из JSON-а искать, сортировать, фильтровать, и вас не заботит ACID, то вполне нормальное решение.
Ответ написан
akubintsev
@akubintsev
Опытный backend разработчик
Обратите внимание на PostgreSQL, у которого есть поддержка таких форматов данных как hstore и jsonb (ожидается в 9.4, сейчас только 3-я бета). Hstore - одноуровневое быстрое key-value хранилище, jsonb - уже иерархическое, которое принимает и отдает json, по нему можно строить выборки запросами.
Ответ написан
FanatPHP
@FanatPHP
Чебуратор тега РНР
1. Это увеличит нагрузку на БД.
2. Само по себе решение продиктовано только дикостью и чудовищным невежеством. Через годика два, если наберешься опыта, то сам с ужасом будешь смотреть на этот свой вопрос.

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

Если взять ларавель, то в модели постов надо будет добавить метод
public function recentComments()
{
    return $this->hasMany('Comment')
        ->orderBy('created_at', 'desc')
        ->limit(3);
}

и ВСЯ лента будет строиться одним оператором, что-то вроде
return Post::orderby('created_at', 'desc')
    ->with([
            'photos',
            'recentComments',
        ]);
    ->limit(5);
Ответ написан
@ugodrus
Если вам так не терпится получать JSON из БД то полистайте вот это.
Вообще сам по себе такой принцип хорош ( извлечение данных в Json ), но только не в кривых руках. Я использовал такое в интернет магазине для выборки товаров. Реально выгоднее по скорости запросов. Чуть тормознутей обычного селекта, но куда быстрей целой серии запросов. Но хранить в Json на мой взгляд уместно лишь небольшие клочки данных. Фрагменты конфигов например.
Ответ написан
@alexey_martynov
Если не рассматривать json даннные в таблице как blob, это нарушение 1NF . Поле должно содержать неделимую информацию. Хранить можно. Можно обрабатывать на клиентской стороне, но нормально пользоваться этим на уровне реляционной БД невозможно и неправильно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы