Продвинутая работа с JSON в MySQL

[@Zeitung]

Не могли бы Вы дать ссылку на статью в которой хотя-бы базово и на пальцах рассматриваются преимущества хранения\использования JSON в БД вместо того чтоб распарсить его в коде приложения? Может я не там смотрю (или нужно попробовать DuckDuckGo), но гугл выдаёт статьи о том как использовать JSON, но не могу найти конретики о выхлопе такого подхода.
Интересуюсь на будущее, т.к. текущий проект на древнейшей DB2, с которой нужно спрыгивать.

[@win0err]

Вкратце: это удобно. Отдал JSON, а у тебя всё по полочкам разложилось.
Почему делать на стороне СУБД — а зачем писать логику на стороне приложения, если можно её реализовать парой команд на стороне СУБД? Меньше кода — меньше ошибок.
Об этом был доклад Коли Самохвалова на Хайлоаде (слайды).

[@Zeitung]

Спасибо, обязательно почитаю.
«по полочкам разложилось» — но в нормальном коде обычно так-же происходит. Т.е. в приведенном в статье примере вы задаёте «маппинг» json->column на SQL, в Java->Spring->Jackson будет DTO класс с аннотациями, который пишеться в базу\отдельные колонки. Конечно если искать по JSON дереву стандартным StreamAPI будет не очень красиво, но есть приличные библиотеки.

[@Zeitung]

Посмотрел доклад, спасибо, было познавательно. Я абсолютно согласен с тем что при возможности на уровень БД нужно выносить (а лучше дублировать) часть валидации и необходимой логики. С другой стороны — мне не приходилось работать с кодом, который бы адекватно транслировал ошибки проверок при манипуировании строками в БД. Но конкретно с JSON… Даже если брать пример докладчика: «пришёл менеджер и сказал что ему нужен доступ к базе данные пофиксить (грубо PHPMyAdmin)», то ему же с JSON придёться бороться? Хотя мне никогда не приходилось работать с системами в которых несколько приложения работают с одной БД (обычно разный UI, но Бекенд\API\DataModel+validation общий)…

[@LastDragon]

это удобно

До тех пор пока не захочется изменить структуру...

[@yushkevichv]

Если совсем на пальцах — хранение json позволяет использовать произвольные структуры данных. Это преимущество не реляционных БД, которое стало возможным использовать и в MySql, весьма добавляет гибкости.
Что касается использования типа данных json в БД (относительно, например, сохранения json в поле с типом text) — есть ряд задач, когда требуется выполнять поиск по json, например.
Из документации Laravel например (https://laravel.com/docs/5.5/queries#json-where-clauses)

$users = DB::table('users')
                ->where('options->language', 'en')
                ->get();

$users = DB::table('users')
                ->where('preferences->dining->meal', 'salad')
                ->get();

Это «выгоднее» отдать на уровень БД.
Код из Laravel привёл для более наглядного примера.

[@Zeitung]

Спасибо. «Произвольные структуры данных» — Вы имеете в виду случаи когда JSON содержит «мусорную» информацию (лишние\случайные ноды)? Ведь если «meal» находиться в разных уровнях вложенности — ничего найдено не будет? Из приведенного примера — я всё-равно пишу путь к интересующему участку… И если брать любую библиотеку для работы с JSON — всё будет примерно также. Хотя в большинстве случаев там будет последовательный перебор массивов (кажется, на Java была либа которая удачно распараллеливала поиск по XPath->XML). Хотя, наверное, на уровне БД должны использовать более «умные» методы поиска?

[@ahdenchik]

От адепта PG ремарка: к «генерации столбцов» нужна ещё «генерация хранимых процедур» и прочие вытекающие из возможности такого рода генерации штуки.