Comments 22
Я плохо представляю себе ситуацию когда в реляционных БД удобно хранить JSON. Точнее я однажды пытался это сделать, но решение получилось до ужаса кривое и я предпочел https://www.arangodb.com
Вам сложно себе представить ситуацию, когда на проекте уже есть всем устраивающая реляционная БД, и надо для какой-то задачи хранить данные произвольного формата (с точки зрения БД — вообще неструктурированные, черный ящик)?
У нас на проекте были несколько мест, где нужно было сделать выборку из 16 таблиц (join). Все было круто, пока не вышла ситуация, когда нам нужно было делать подобные запросы n -раз за один запрос! Вот тут мы и почувствовали, как не сладко приходится нашему Postgre, когда у него залетали запросы по 56 килобайт и таких запросов было много. Тогда мы решили все эти таблицы просто перенести в одно поле, не json, простой текст, нам нужно было с ними работать только на чтение, без сортировок и условий.
Да, тот запрос разгрузился просто в десятки раз!
Конечно на плечи приложения упала логика корректного заполнения этого поля и его контроль, но мы ни разу не пожалели об этом!
Да, тот запрос разгрузился просто в десятки раз!
Конечно на плечи приложения упала логика корректного заполнения этого поля и его контроль, но мы ни разу не пожалели об этом!
Как-то раз нужно было хранить 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.
Может в будущем что-то хорошее и появится. Предложенные сейчас в качестве обхода генерируемые поля довольно интересно выглядят. Я, правда, пока не понял, куда их применять, но всё равно интересно
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\»" если ключ содержит пробелы
Тут нет никакой ошибки? Реально ёлочки надо ставить?
Возник вопрос: допустим мы храним в поле "names" json массив ["Василий", "Петр", "Василий", "Сергей"]. Как выбрать из этого массива уникальные (distinct) значения?
Конечно, могу ошибаться, похоже нужно вынимать строку из базы и отдельно проверять массив на наличие совпадений, т.к., насколько я понял, DISTINCT делает обработку среди записей таблицы, а не внутри каждой строки.
Вот тут написано об использовании метода "distinct" класса "MongoCollection".
Вот тут написано об использовании метода "distinct" класса "MongoCollection".
Хоть дока и для монго, можно попытаться реализовать нечто подобное для MySQL.
Не факт, конечно, но как вариант.
Не факт, конечно, но как вариант.
Sign up to leave a comment.
Декодирование типа данных JSON MySQL