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

[beduin01]

Я плохо представляю себе ситуацию когда в реляционных БД удобно хранить JSON. Точнее я однажды пытался это сделать, но решение получилось до ужаса кривое и я предпочел https://www.arangodb.com

[lair]

Вам сложно себе представить ситуацию, когда на проекте уже есть всем устраивающая реляционная БД, и надо для какой-то задачи хранить данные произвольного формата (с точки зрения БД — вообще неструктурированные, черный ящик)?

[beduin01]

Хранение JSON в реляционной БД не сильно превосходит хранение там простых текстовых строк. Те же самые неудобства и сложности.

[zelenin]

возможность делать запросы по полям json и индексы — это полностью превосходит хранение простых текстовых строк.

[lair]

Но тем не менее текстовые строки мы в БД храним. Тогда почему не хранить и JSON?

[Rathil]

У нас на проекте были несколько мест, где нужно было сделать выборку из 16 таблиц (join). Все было круто, пока не вышла ситуация, когда нам нужно было делать подобные запросы n -раз за один запрос! Вот тут мы и почувствовали, как не сладко приходится нашему Postgre, когда у него залетали запросы по 56 килобайт и таких запросов было много. Тогда мы решили все эти таблицы просто перенести в одно поле, не json, простой текст, нам нужно было с ними работать только на чтение, без сортировок и условий.
Да, тот запрос разгрузился просто в десятки раз!
Конечно на плечи приложения упала логика корректного заполнения этого поля и его контроль, но мы ни разу не пожалели об этом!

[Rathil]

За один https request.

[Helldar]

Как-то раз нужно было хранить JSON-строку в базе. Создал колонку типа TEXT и обращался к ней через json_encode / json_decode. Проект был мал в масштабах, поэтому решение подходило более чем.

[Methos]

То есть, там внутри будет какой-то индекс по полям и поиск будет быстрым?

[Starche]

Этот вопрос лично меня заинтересовал в первую очередь, но нет. не судьба
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.
Может в будущем что-то хорошее и появится. Предложенные сейчас в качестве обхода генерируемые поля довольно интересно выглядят. Я, правда, пока не понял, куда их применять, но всё равно интересно

[alxpy]

В PostgreSQL есть, если интересно.

[savostin]

Ну почему каждый считает своим долгом выдумать новый синтаксис? Все эти доллары, звездочки… Больное воображение какое-то.

[rakot]

specs->"$.\«key name with space\»" если ключ содержит пробелы

Тут нет никакой ошибки? Реально ёлочки надо ставить?

[Helldar]

Нет, не елочки = это "кавычки" — хабр так обработал символы

[DimNS]

Внесу свои 5 копеек, кавычки двойные или одиночные, судя по логике запроса одиночные кавычки, все верно?

[Helldar]

Судя по логике да. Статью исправил.

[DimNS]

Вот, так стало гораздо понятнее, спасибо

[misterio]

Возник вопрос: допустим мы храним в поле "names" json массив ["Василий", "Петр", "Василий", "Сергей"]. Как выбрать из этого массива уникальные (distinct) значения?

[Helldar]

Конечно, могу ошибаться, похоже нужно вынимать строку из базы и отдельно проверять массив на наличие совпадений, т.к., насколько я понял, DISTINCT делает обработку среди записей таблицы, а не внутри каждой строки.
Вот тут написано об использовании метода "distinct" класса "MongoCollection".

[Helldar]

Хоть дока и для монго, можно попытаться реализовать нечто подобное для MySQL.
Не факт, конечно, но как вариант.

[misterio]

Да, не вышло. Жалко в MySQL нет этого функционала