Декодирование типа данных JSON MySQL

http://themsaid.github.io/mysql-json-data-type-20160311/
  • Перевод
В этом посте мы собираемся исследовать тип данных JSON в MySQL 5.7 и во время погружения будем использовать фреймворк Laravel для построения запросов.

image


Для начала, создадим новую таблицу:

CREATE TABLE `products` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` JSON,
`specs` JSON,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;


И добавим несколько значений:

INSERT INTO products VALUES(
    null,
    '{"en": "phone", "it": "telefono"}',
    '{"colors": ["black", "white", "gold"], "size": {"weight": 1, "height": 1}}'
);

INSERT INTO products VALUES(
    null,
    '{"en": "screen", "it": "schermo"}',
    '{"colors": ["black", "silver"], "size": {"weight": 2, "height": 3}}'
);

INSERT INTO products VALUES(
    null,
    '{"en": "car", "it": "auto"}',
    '{"colors": ["red", "blue"], "size": {"weight": 40, "height": 34}}'
);


Считывание значений JSON



Мы можем прочесть значения JSON-колонки используя простой синтаксис:

select
name->"$.en" as name,
specs->"$.size.weight" as weight,
specs->"$.colors" as colors
from products;


Получим следующий результат:

name weight colors
'phone' 1 ['black', 'white', 'gold']
'screen' 2 ['black', 'silver']
'car' 40 ['red', 'blue']


Как вы, возможно, заметили, результаты получены в виде строки в формате JSON, это означает, что вам нужно декодировать их перед выводом на экран.

json_decode( Products::selectRaw('name->"$.en" as name')->first()->name )


О синтаксисе



Выполнение запросов в формате JSON осуществляется через оператор "->", слева размещая имя столбца оператора, а справа синтаксис пути.

Для представления документа в JSON-формате с последующим селектором, синтаксис PATH использует ведущую $ для указания на конкретные части документа. Вот различные пути для извлечения данных:

  • specs->"$.colors" вернет массив цветов
  • specs->"$.colors[0]" вернет JSON-строку «black»
  • specs->"$.non_existing" вернет NULL
  • specs->"$.'key name with space'" если ключ содержит пробелы


Если ключ не является допустимым идентификатором ECMAScript, он должен быть заключен в кавычки внутри пути.

Использование подстановок



Вы также можете использовать маску для запроса значений JSON. Допустим, мы имеем следующие данные:

{"name": "phone", "price": 400, "sizes": [3, 4, 5]}


Синтаксис Результат Примечание
specs->"$.*" ['phone', [3, 4, 5], [{'name': 'black'}, {'name': 'gold'}]]
specs->"$.sizes[*]" [3, 4, 5] То же, что и $.sizes
specs->"$.colors**.name" ['black', 'gold'] Синтаксис «префикс**суффикс» будет запрашивать все пути, начинающиеся с префикса и заканчивающиеся суффиксом.


Запрос значения в формате JSON



Это работает также, как и в обычных колонках MySQL. Теперь, когда мы знаем как написать правильный путь для запроса и/или сортировки значений в JSON-формате, посмотрим некоторые примеры:

select name->"$.en" from products where name->"$.en" = "phone";

select name->"$.en" from products where name->"$.en" IN ("phone");

select specs->"$.size.weight" from products where specs->"$.size.weight" BETWEEN 1 AND 10;

select * from products ORDER BY name->"$.en";


Тип данных JSON в MySQL и фреймворк Laravel



Если Вы используете фреймворк Laravel версии 5.2.23 или выше, Вы будете иметь возможность свободно использовать конструктор запросов для формирования запроса в формате JSON:

Product::where('name->en', 'car')->first();

Product::whereIn('specs->size->weight', [1, 2, 3])->get();

Product::select('name->en')->orderBy('specs->size->height', 'DESC')->get();


Если нет, то Вы нужно использовать RAW:

Product::whereRaw('name->"$.en"', 'car')->first();


Вывод



Во многих случаях, разработчики предпочитают базу данных NoSQL для специфических особенностей, гибкости и/или производительности, однако базы данных SQL являются предпочтительными и много крупных компаний полагаются на них при разработке производительных веб-приложений, используя для этого связку MySQL + (Mongo|Redis|и т.д.), но это добавляет сложности в стек. С введением типа данных JSON в MySQL, он стал своего рода гибридной базой данных SQL-NoSQL.

От переводчика


В примерах там, где видны «елочки» — нужно ставить «кавычки». Это Хабр так их обрабатывает.
Поделиться публикацией
Похожие публикации
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 22
    –5
    Я плохо представляю себе ситуацию когда в реляционных БД удобно хранить JSON. Точнее я однажды пытался это сделать, но решение получилось до ужаса кривое и я предпочел https://www.arangodb.com
      +3
      Вам сложно себе представить ситуацию, когда на проекте уже есть всем устраивающая реляционная БД, и надо для какой-то задачи хранить данные произвольного формата (с точки зрения БД — вообще неструктурированные, черный ящик)?
        –4
        Хранение JSON в реляционной БД не сильно превосходит хранение там простых текстовых строк. Те же самые неудобства и сложности.
          +6
          возможность делать запросы по полям json и индексы — это полностью превосходит хранение простых текстовых строк.
            +3
            Но тем не менее текстовые строки мы в БД храним. Тогда почему не хранить и JSON?
          +2
          У нас на проекте были несколько мест, где нужно было сделать выборку из 16 таблиц (join). Все было круто, пока не вышла ситуация, когда нам нужно было делать подобные запросы n -раз за один запрос! Вот тут мы и почувствовали, как не сладко приходится нашему Postgre, когда у него залетали запросы по 56 килобайт и таких запросов было много. Тогда мы решили все эти таблицы просто перенести в одно поле, не json, простой текст, нам нужно было с ними работать только на чтение, без сортировок и условий.
          Да, тот запрос разгрузился просто в десятки раз!
          Конечно на плечи приложения упала логика корректного заполнения этого поля и его контроль, но мы ни разу не пожалели об этом!
            0
            За один https request.
            +1
            А я отлично представляю.А-ааа!
              +1
              Как-то раз нужно было хранить JSON-строку в базе. Создал колонку типа TEXT и обращался к ней через json_encode / json_decode. Проект был мал в масштабах, поэтому решение подходило более чем.
              +2
              То есть, там внутри будет какой-то индекс по полям и поиск будет быстрым?
                0
                Этот вопрос лично меня заинтересовал в первую очередь, но нет. не судьба
                JSON columns cannot be indexed. You can work around this restriction by creating an index on a generated column that extracts a scalar value from the JSON column. See Secondary Indexes and Virtual Generated Columns, for a detailed example.
                Может в будущем что-то хорошее и появится. Предложенные сейчас в качестве обхода генерируемые поля довольно интересно выглядят. Я, правда, пока не понял, куда их применять, но всё равно интересно
                  +1
                  В PostgreSQL есть, если интересно.
                  +2
                  Ну почему каждый считает своим долгом выдумать новый синтаксис? Все эти доллары, звездочки… Больное воображение какое-то.
                    0
                    specs->"$.\«key name with space\»" если ключ содержит пробелы

                    Тут нет никакой ошибки? Реально ёлочки надо ставить?
                      0
                      Нет, не елочки = это "кавычки" — хабр так обработал символы
                        0
                        Внесу свои 5 копеек, кавычки двойные или одиночные, судя по логике запроса одиночные кавычки, все верно?
                          0
                          Судя по логике да. Статью исправил.
                            +1
                            Вот, так стало гораздо понятнее, спасибо
                      0
                      Возник вопрос: допустим мы храним в поле "names" json массив ["Василий", "Петр", "Василий", "Сергей"]. Как выбрать из этого массива уникальные (distinct) значения?
                        0
                        Конечно, могу ошибаться, похоже нужно вынимать строку из базы и отдельно проверять массив на наличие совпадений, т.к., насколько я понял, DISTINCT делает обработку среди записей таблицы, а не внутри каждой строки.
                        Вот тут написано об использовании метода "distinct" класса "MongoCollection".
                          0
                          Хоть дока и для монго, можно попытаться реализовать нечто подобное для MySQL.
                          Не факт, конечно, но как вариант.
                            +1
                            Да, не вышло. Жалко в MySQL нет этого функционала

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое