Comments 10
Не могли бы Вы дать ссылку на статью в которой хотя-бы базово и на пальцах рассматриваются преимущества хранения\использования JSON в БД вместо того чтоб распарсить его в коде приложения? Может я не там смотрю (или нужно попробовать DuckDuckGo), но гугл выдаёт статьи о том как использовать JSON, но не могу найти конретики о выхлопе такого подхода.
Интересуюсь на будущее, т.к. текущий проект на древнейшей DB2, с которой нужно спрыгивать.
Интересуюсь на будущее, т.к. текущий проект на древнейшей DB2, с которой нужно спрыгивать.
Спасибо, обязательно почитаю.
«по полочкам разложилось» — но в нормальном коде обычно так-же происходит. Т.е. в приведенном в статье примере вы задаёте «маппинг» json->column на SQL, в Java->Spring->Jackson будет DTO класс с аннотациями, который пишеться в базу\отдельные колонки. Конечно если искать по JSON дереву стандартным StreamAPI будет не очень красиво, но есть приличные библиотеки.
«по полочкам разложилось» — но в нормальном коде обычно так-же происходит. Т.е. в приведенном в статье примере вы задаёте «маппинг» json->column на SQL, в Java->Spring->Jackson будет DTO класс с аннотациями, который пишеться в базу\отдельные колонки. Конечно если искать по JSON дереву стандартным StreamAPI будет не очень красиво, но есть приличные библиотеки.
Посмотрел доклад, спасибо, было познавательно. Я абсолютно согласен с тем что при возможности на уровень БД нужно выносить (а лучше дублировать) часть валидации и необходимой логики. С другой стороны — мне не приходилось работать с кодом, который бы адекватно транслировал ошибки проверок при манипуировании строками в БД. Но конкретно с JSON… Даже если брать пример докладчика: «пришёл менеджер и сказал что ему нужен доступ к базе данные пофиксить (грубо PHPMyAdmin)», то ему же с JSON придёться бороться? Хотя мне никогда не приходилось работать с системами в которых несколько приложения работают с одной БД (обычно разный UI, но Бекенд\API\DataModel+validation общий)…
это удобно
До тех пор пока не захочется изменить структуру...
Если совсем на пальцах — хранение json позволяет использовать произвольные структуры данных. Это преимущество не реляционных БД, которое стало возможным использовать и в MySql, весьма добавляет гибкости.
Что касается использования типа данных json в БД (относительно, например, сохранения json в поле с типом text) — есть ряд задач, когда требуется выполнять поиск по json, например.
Из документации Laravel например (https://laravel.com/docs/5.5/queries#json-where-clauses)
Это «выгоднее» отдать на уровень БД.
Код из Laravel привёл для более наглядного примера.
Что касается использования типа данных 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 привёл для более наглядного примера.
Спасибо. «Произвольные структуры данных» — Вы имеете в виду случаи когда JSON содержит «мусорную» информацию (лишние\случайные ноды)? Ведь если «meal» находиться в разных уровнях вложенности — ничего найдено не будет? Из приведенного примера — я всё-равно пишу путь к интересующему участку… И если брать любую библиотеку для работы с JSON — всё будет примерно также. Хотя в большинстве случаев там будет последовательный перебор массивов (кажется, на Java была либа которая удачно распараллеливала поиск по XPath->XML). Хотя, наверное, на уровне БД должны использовать более «умные» методы поиска?
UFO just landed and posted this here
От адепта PG ремарка: к «генерации столбцов» нужна ещё «генерация хранимых процедур» и прочие вытекающие из возможности такого рода генерации штуки.
UFO just landed and posted this here
Sign up to leave a comment.
Продвинутая работа с JSON в MySQL