Как стать автором
Обновить

Комментарии 22

Я плохо представляю себе ситуацию когда в реляционных БД удобно хранить JSON. Точнее я однажды пытался это сделать, но решение получилось до ужаса кривое и я предпочел https://www.arangodb.com
Вам сложно себе представить ситуацию, когда на проекте уже есть всем устраивающая реляционная БД, и надо для какой-то задачи хранить данные произвольного формата (с точки зрения БД — вообще неструктурированные, черный ящик)?
Хранение JSON в реляционной БД не сильно превосходит хранение там простых текстовых строк. Те же самые неудобства и сложности.
возможность делать запросы по полям json и индексы — это полностью превосходит хранение простых текстовых строк.
Но тем не менее текстовые строки мы в БД храним. Тогда почему не хранить и JSON?
У нас на проекте были несколько мест, где нужно было сделать выборку из 16 таблиц (join). Все было круто, пока не вышла ситуация, когда нам нужно было делать подобные запросы n -раз за один запрос! Вот тут мы и почувствовали, как не сладко приходится нашему Postgre, когда у него залетали запросы по 56 килобайт и таких запросов было много. Тогда мы решили все эти таблицы просто перенести в одно поле, не json, простой текст, нам нужно было с ними работать только на чтение, без сортировок и условий.
Да, тот запрос разгрузился просто в десятки раз!
Конечно на плечи приложения упала логика корректного заполнения этого поля и его контроль, но мы ни разу не пожалели об этом!
За один https request.
НЛО прилетело и опубликовало эту надпись здесь
Как-то раз нужно было хранить JSON-строку в базе. Создал колонку типа TEXT и обращался к ней через json_encode / json_decode. Проект был мал в масштабах, поэтому решение подходило более чем.
То есть, там внутри будет какой-то индекс по полям и поиск будет быстрым?
Этот вопрос лично меня заинтересовал в первую очередь, но нет. не судьба
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.
Может в будущем что-то хорошее и появится. Предложенные сейчас в качестве обхода генерируемые поля довольно интересно выглядят. Я, правда, пока не понял, куда их применять, но всё равно интересно
В PostgreSQL есть, если интересно.
Ну почему каждый считает своим долгом выдумать новый синтаксис? Все эти доллары, звездочки… Больное воображение какое-то.
specs->"$.\«key name with space\»" если ключ содержит пробелы

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