Хранение данных в MySQL как JSON

121

Я подумал, что это непростая задача. Итак, я никогда этого не делал. Затем я увидел, что FriendFeed сделал это и фактически улучшил масштабирование своей БД и уменьшил задержку. Мне любопытно, стоит ли мне это сделать. И если да, то как правильно это сделать?

В принципе, где можно научиться хранить все в MySQL как БД типа CouchDB? Кажется, что хранить все в формате JSON будет проще и быстрее (не для сборки, с меньшей задержкой).

Кроме того, легко ли редактировать, удалять и т. Д. Вещи, хранящиеся как JSON в БД?

Оскар Годсон
источник
Для справки, я полагаю, что это обсуждение FriendFeed по использованию JSON в MySQL: backchannel.org/blog/friendfeed-schemaless-mysql
dimo414
10
MySQL 5.7 теперь поддерживает собственное хранилище данных JSON.
eecue

Ответы:

57

CouchDB и MySQL - два очень разных зверя. JSON - это собственный способ хранения данных в CouchDB. В MySQL лучшее, что вы могли сделать, - это хранить данные JSON в виде текста в одном поле. Это полностью лишило бы смысла сохранение его в СУБД и значительно усложнило бы каждую транзакцию базы данных.

Не.

Сказав это, FriendFeed, похоже, использовал чрезвычайно настраиваемую схему поверх MySQL. Это действительно зависит от того, что именно вы хотите сохранить, вряд ли есть однозначный ответ о том, как злоупотреблять системой баз данных, чтобы это имело смысл для вас. Учитывая, что статья очень старая и их основной причиной против Mongo и Couch была незрелость, я бы переоценил эти две, если MySQL не подойдет вам. К настоящему времени они должны были сильно подрасти.

обмануть
источник
3
Да, я смотрю на Mongo, и у php есть расширение для него, и фактический синтаксис транзакций БД кажется проще, чем MySQL, и в целом работа с ним кажется проще, чем couchDB. Спасибо, я думаю, что собираюсь пойти с MongoDB :)
Оскар Годсон
68
Конечно, существуют допустимые случаи для хранения BLOB-объектов JSON в СУБД. Если вы просто хотите хранить и извлекать непрозрачные капли данных JSON без необходимости запрашивать эти данные, что довольно часто случается в некоторых сценариях, вы вполне можете это сделать.
Маркус 08
9
@markus На самом деле я делаю это на одном из своих веб-сайтов, в частности в полях сложной формы, которые никогда не ищутся напрямую в запросах MySQL, но используются при просмотре форм (либо из табличного представления, либо напрямую по ссылке). Это, вероятно, не идеально, но, безусловно, значительно ускоряет реализацию и устраняет необходимость в непомерном количестве таблиц или столбцов таблиц.
Ник Бедфорд
1
Если вы хотите иметь как СУБД, так и хранилище типов документов для своего приложения, это хороший подход, поэтому вам не нужно управлять несколькими базами данных.
rjarmstrong 01
5
Это довольно краткий совет, возможно, от того, кто слишком много времени тратит на обмен стеками? Когда у меня есть запись со 100 полями, которые я хочу сохранить, и мне нужно искать только по 3 или 4 полям, создание таблицы со 100 полями бессмысленно. Вы можете сохранить запись клиента со всей его адресной книгой, хранящейся в одном поле в JSON, и просто добавить идентификатор клиента, фамилию, компанию в качестве других полей для использования для поиска записей. Это. огромная экономия времени.
Danial
102

Кажется, что все, кто комментирует, приходят к этому с неправильной точки зрения, можно хранить код JSON через PHP в реляционной БД, и на самом деле будет быстрее загружать и отображать такие сложные данные, однако у вас будут соображения дизайна, такие как поиск, индексация и т. д.

Лучший способ сделать это - использовать гибридные данные, например, если вам нужно выполнить поиск на основе datetime, MySQL (с настроенной производительностью) будет намного быстрее, чем PHP, и для чего-то вроде расстояния поиска мест MySQL также должно быть много быстрее (обратите внимание, что поиск не дает доступа). Данные, которые вам не нужно искать, могут быть сохранены в JSON, BLOB или любом другом формате, который вы действительно сочтете необходимым.

Данные, к которым вам нужен доступ, очень легко сохранить в виде JSON, например, в базовой системе счетов-фактур для каждого случая. Они не сильно выигрывают от РСУБД и могут быть сохранены в JSON только с помощью json_encoding ($ _ POST ['entires']), если у вас есть правильная структура HTML-формы.

Я рад, что вам нравится использовать MongoDB, и надеюсь, что он по-прежнему будет вам хорошо служить, но не думайте, что MySQL всегда будет вне поля вашего зрения, поскольку ваше приложение становится все сложнее, и вам вполне может потребоваться СУБД для некоторые функции и возможности (даже если это просто для удаления архивных данных или бизнес-отчетности)

Льюис Ричард Филлип Коулз
источник
8
-1 для «нормально хранить код JSON через PHP в реляционной БД» - Хранение JSON (который может представлять всю сущность как неатомарные данные) в одном поле нарушает реляционную модель и предотвращает 1NF. Кроме того, не делайте резких заявлений о производительности без поддерживающих вас показателей.
Sage Gerard
80
Как уже упоминалось, это зависит от того, что вы храните, то есть для счета-фактуры вам действительно нужно хранить каждую запись отдельно? НЕТ, ваш комментарий выглядит так, как будто вы так много знаете, но 1NF не для каждого поля, иначе не было бы типов BLOB и текста ... это чистая ерунда для производственной системы, вам нужно только оптимизировать то, что вам нужно для поиска т.е. даты, ключи и настроить индексы для некоторых данных. Я не сказал хранить все как JSON, я сказал, что храните некоторые данные как JSON, если это поможет решить вашу проблему.
Льюис Ричард Филлип Коулз
2
То, что вы говорите, возможно и удобно, но отклонение от правильно сформированных отношений означает выполнение большей работы по устранению и сохранению указанных отклонений. Уничтожение реляционной модели требует лучшего обоснования, чем то, что вы предоставили. См. Обработку базы данных Кроенке и Ауэром для получения дополнительной информации о сложностях, связанных с вашим ответом, поскольку они касаются неправильного использования атрибутов в отношениях.
Sage Gerard
29
Вы предполагаете, что я не консультировался с администратором баз данных по этому вопросу и не понимаю, о чем вы говорите. Я не знаю, каковы последствия этого как для небольших систем, так и для других, но я говорю, что вы ошибаетесь и что исследование, на которое вы указываете, является старым и не использует наше приложение. стратегия. Это просто неправильно, и проблемы кроются в плохой реализации этого процесса. Например, я не говорю, что у вас есть только одна модель или вы не используете СУБД, я говорю, что будьте внимательны в отношении того, где вы используете СУБД, а где вам это не нужно.
Льюис Ричард Филлип Коулз
6
Это был лучший ответ из моего опыта. Вы можете использовать СУБД, но хранить JSON только в определенных ситуациях, если вы знаете, что делаете. Фактически, я часто использовал его для временного кеш-хранилища данных массива и некоторых других ситуаций, когда вы достигаете более быстрого результата и меньшего количества кода. Многие проекты на самом деле имеют смешанные черты.
Героселохим 05
72

MySQL 5.7 теперь поддерживает собственный тип данных JSON, аналогичный MongoDB и другим хранилищам данных документов без схемы:

Поддержка JSON

Начиная с MySQL 5.7.8, MySQL поддерживает собственный тип JSON. Значения JSON не хранятся в виде строк, вместо этого используется внутренний двоичный формат, который обеспечивает быстрый доступ для чтения к элементам документа. Документы JSON, хранящиеся в столбцах JSON, автоматически проверяются всякий раз, когда они вставляются или обновляются, а недопустимый документ вызывает ошибку. Документы JSON нормализуются при создании и могут сравниваться с помощью большинства операторов сравнения, таких как =, <, <=,>,> =, <>,! = И <=>; для получения информации о поддерживаемых операторах, а также о приоритете и других правилах, которым MySQL следует при сравнении значений JSON, см. Сравнение и упорядочение значений JSON.

MySQL 5.7.8 также вводит ряд функций для работы со значениями JSON. Эти функции включают перечисленные здесь:

  1. Функции, которые создают значения JSON: JSON_ARRAY (), JSON_MERGE () и JSON_OBJECT (). См. Раздел 12.16.2, «Функции, которые создают значения JSON».
  2. Функции, выполняющие поиск значений JSON: JSON_CONTAINS (), JSON_CONTAINS_PATH (), JSON_EXTRACT (), JSON_KEYS () и JSON_SEARCH (). См. Раздел 12.16.3, «Функции, выполняющие поиск значений JSON».
  3. Функции, изменяющие значения JSON: JSON_APPEND (), JSON_ARRAY_APPEND (), JSON_ARRAY_INSERT (), JSON_INSERT (), JSON_QUOTE (), JSON_REMOVE (), JSON_REPLACE (), JSON_SET () и JSON )_UNQUOTE (). См. Раздел 12.16.4, «Функции, изменяющие значения JSON».
  4. Функции, предоставляющие информацию о значениях JSON: JSON_DEPTH (), JSON_LENGTH (), JSON_TYPE () и JSON_VALID (). См. Раздел 12.16.5, «Функции, возвращающие атрибуты значений JSON».

В MySQL 5.7.9 и новее вы можете использовать столбец-> путь как сокращение для JSON_EXTRACT (столбец, путь). Это работает как псевдоним для столбца везде, где идентификатор столбца может встречаться в операторе SQL, включая предложения WHERE, ORDER BY и GROUP BY. Сюда входят SELECT, UPDATE, DELETE, CREATE TABLE и другие операторы SQL. В левой части должен быть идентификатор столбца JSON (а не псевдоним). Правая сторона - это указанное в кавычках выражение пути JSON, которое оценивается по документу JSON, возвращаемому в качестве значения столбца.

См. Раздел 12.16.3, «Функции, выполняющие поиск значений JSON», для получения дополнительной информации о -> и JSON_EXTRACT (). Для получения информации о поддержке пути JSON в MySQL 5.7 см. Поиск и изменение значений JSON. См. Также Вторичные индексы и Виртуальные генерируемые столбцы.

Больше информации:

https://dev.mysql.com/doc/refman/5.7/en/json.html

eecue
источник
26

json-символы не представляют собой ничего особенного, когда дело доходит до хранения, такие символы, как

{, }, [, ], ', a-z, 0-9.... нет ничего особенного , и могут быть сохранены в виде текста.

первая проблема, с которой вы столкнетесь, это

{profile_id: 22, имя пользователя: 'Роберт', пароль: 'skhgeeht893htgn34ythg9er'}

которые хранятся в базе данных, не так просто обновить, если у вас нет собственной процедуры и не разработан jsondecode для mysql

UPDATE users SET JSON(user_data,'username') = 'New User';

Так как вы не можете этого сделать, вам придется сначала ВЫБРАТЬ json, декодировать его, изменить, обновить, так что теоретически вы могли бы потратить больше времени на создание подходящей структуры базы данных!

Я использую json для хранения данных, но только метаданные, данные, которые не обновляются часто, не связанные с конкретным пользователем .. пример, если пользователь добавляет сообщение, и в этом сообщении он добавляет изображения, плохо разбирает изображения и создает большие пальцы и затем используйте URL-адреса большого пальца в формате json.

RobertPitt
источник
Достаточно ли хорошо хранить строку json в базе данных, когда я ее вообще не обновляю? Я просто хочу выполнить обычный поиск данных json с помощью LIKE. Я вижу, что даже Wordpress хранит метаданные плагина в виде строки json в базе данных.
shasi kanth
@shasikanth, если вы ищете значения в данных JSON, я бы поискал лучший подход
Кирби
15

Чтобы проиллюстрировать, насколько сложно получить данные JSON с помощью запроса, я поделюсь запросом, который я сделал для этого.

Он не принимает во внимание массивы или другие объекты, а только основные типы данных. Вы должны изменить 4 экземпляра столбца на имя столбца, в котором хранится JSON, и изменить 4 экземпляра myfield на поле JSON, к которому вы хотите получить доступ.

SELECT
    SUBSTRING(
        REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
        LOCATE(
            CONCAT('myfield', ':'),
            REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
        ) + CHAR_LENGTH(CONCAT('myfield', ':')),
        LOCATE(
            ',',
            SUBSTRING(
                REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', ''),
                LOCATE(
                    CONCAT('myfield', ':'),
                    REPLACE(REPLACE(REPLACE(column, '{', ''), '}', ','), '"', '')
                ) + CHAR_LENGTH(CONCAT('myfield', ':'))
            )
        ) - 1
    )
    AS myfield
FROM mytable WHERE id = '3435'
Jorjon
источник
5
Вы бы не стали запрашивать эту серверную часть. Это будет для хранения blob-объекта и его возврата на клиентскую сторону. Затем вы просто использовали JS для запроса. Это было давно, хотя :) С тех пор я перешел на MongoDB для этого :) Проголосуйте за этот симпатичный запрос.
Оскар Годсон
Я думаю, вопрос в том, собирается ли человек регулярно получать доступ к этим данным JSON. В примере я перемещаю несущественные заголовки в массив, разбираю в JSON и затем сохраняю. Когда я получу JSON (для редкого запроса AJAX с дополнительными заголовками), я просто возьму из MySQL, прочитаю JSON в массив и выведу заголовки. Для чего-то более интенсивного, вероятно, не следует хранить его как JSON.
Джон
10

Это действительно зависит от вашего варианта использования. Если вы храните информацию, которая не имеет абсолютно никакого значения в отчетах и ​​не будет запрашиваться через JOINs с другими таблицами, может иметь смысл хранить ваши данные в одном текстовом поле, закодированном как JSON.

Это может значительно упростить вашу модель данных. Однако, как упоминал Роберт Питт, не ожидайте, что сможете объединить эти данные с другими нормализованными данными.

Фил Ланаса
источник
2
Мои мысли точно. Если его данные никогда не объединяются / не просматриваются или даже редко обновляются, почему бы не использовать json в поле ТЕКСТ. Хорошим примером этого является таблица fooditem, в которой каждый продукт должен хранить информацию о пищевой ценности. Размер порции, протеин, углеводы, общее количество жиров, насыщение жиров и т. Д. Но не только это, вам нужно будет сохранить значение (0,2) и единицу измерения (г, унция, жидкая унция, мл). Учитывая, что это данные, которые (в зависимости от того, что вы делаете, я думаю) не нужно искать, я бы сказал, что 1 ТЕКСТ против 16 столбцов int / varchar / enum - хороший компромисс.
Брэд Мур
Именно!!! Это полезно, когда вам нужно хранить переменную и / или неизвестную структуру данных, которую вы вообще не планируете фильтровать с помощью SQL. Данные просто хранятся как есть, и кто-то другой (код приложения) может знать структуру и что с ней делать.
Delmo
9

Это старый вопрос, но я все еще могу видеть его в верхней части результатов поиска Google, поэтому я думаю, было бы целесообразно добавить новый ответ через 4 года после того, как вопрос будет задан.

Прежде всего, улучшена поддержка хранения JSON в СУБД. Вы можете подумать о переходе на PostgreSQL (хотя MySQL поддерживает JSON с версии v5.7.7). PostgreSQL использует очень похожие команды SQL, как и MySQL, за исключением того, что они поддерживают больше функций. Одна из добавленных функций заключается в том, что они предоставляют тип данных JSON, и теперь вы можете запрашивать сохраненный JSON. ( Некоторая ссылка на это ) Если вы не составляете запрос непосредственно в своей программе, например, используя PDO в php или красноречиво в Laravel, все, что вам нужно сделать, это просто установить PostgreSQL на свой сервер и изменить настройки подключения к базе данных. Вам даже не нужно менять свой код.

В большинстве случаев, как предполагали другие ответы, хранение данных в виде JSON непосредственно в СУБД не является хорошей идеей. Однако есть некоторые исключения. Одна ситуация, о которой я могу думать, - это поле с переменным количеством связанных записей.

Например, для хранения тега сообщения в блоге обычно требуется таблица для сообщения в блоге, таблица тегов и таблица соответствия. Итак, когда пользователь хочет отредактировать сообщение, и вам нужно отобразить, какой тег связан с этим сообщением, вам нужно будет запросить 3 таблицы. Это сильно повредит производительности, если ваша таблица соответствия / таблица тегов будет длинной.

Сохраняя теги в виде JSON в таблице сообщений блога, одно и то же действие требует поиска только одной таблицы. После этого пользователь сможет увидеть сообщение в блоге, которое будет редактироваться быстрее, но это снизит производительность, если вы захотите создать отчет о том, какое сообщение связано с тегом, или, возможно, выполнить поиск по тегу.

Вы также можете попробовать денормализовать базу данных. Дублируя данные и сохраняя данные обоими способами, вы можете получить преимущества обоих методов. Вам просто потребуется немного больше времени для хранения ваших данных и больше места для хранения (что дешево по сравнению с затратами на большую вычислительную мощность)

cytsunny
источник
8

Я бы сказал, что есть только две причины для этого:

  • производительность просто недостаточно хороша с нормализованным подходом
  • вы не можете легко смоделировать свои особенно подвижные / гибкие / изменяющиеся данные

Я немного написал о своем подходе здесь:

С какими проблемами масштабируемости вы столкнулись при использовании хранилища данных NoSQL?

(см. верхний ответ)

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

Есть ли причина, по которой вы не используете что-то вроде MongoDB? (может быть MySQL "требуется"; просто любопытно)

Брайан
источник
6

Мне кажется, что каждый, кто отвечает на этот вопрос, как бы упускает из виду одну критическую проблему, кроме @deceze - используйте правильный инструмент для работы . Вы можете заставить реляционную базу данных хранить почти любой тип данных, и вы можете заставить Mongo обрабатывать реляционные данные, но какой ценой? В итоге вы усложняете все уровни разработки и сопровождения, от дизайна схемы до кода приложения; не говоря уже о производительности.

В 2014 году у нас есть доступ ко многим серверам баз данных, которые исключительно хорошо обрабатывают определенные типы данных.

  • Mongo (хранилище документов)
  • Redis (хранилище данных ключ-значение)
  • MySQL / Maria / PostgreSQL / Oracle / и т. Д. (Реляционные данные)
  • CouchDB (JSON)

Я уверен, что скучал по некоторым другим, таким как RabbirMQ и Cassandra. Я хочу сказать, что используйте правильный инструмент для данных, которые вам нужно хранить.

Если вашему приложению требуется действительно очень быстрое хранение и извлечение различных данных (а кто этого не делает), не уклоняйтесь от использования нескольких источников данных для приложения. Большинство популярных веб-фреймворков обеспечивают поддержку нескольких источников данных (Rails, Django, Grails, Cake, Zend и т. Д.). Эта стратегия ограничивает сложность одной конкретной областью приложения, ORM или интерфейсом источника данных приложения.

CheddarMonkey
источник
1
На ваш взгляд RabbitMQ - это сервер баз данных или что-то вроде этого? Я бы сказал, что это промежуточное программное обеспечение, ориентированное на сообщения, с небольшой приятной функцией сохранения, чтобы не терять никаких сообщений, но не с чем я бы сохранял данные. Всего два цента.
Osiriz 06
@Osiriz: Вы правы. Я, наверное, не должен был включать это в это обсуждение.
CheddarMonkey
5

Вот функция, которая будет сохранять / обновлять ключи массива JSON в столбце, и другая функция, которая извлекает значения JSON. Эти функции создаются при условии, что имя столбца для хранения массива JSON - json . Он использует PDO .

Функция сохранения / обновления

function save($uid, $key, $val){
 global $dbh; // The PDO object
 $sql = $dbh->prepare("SELECT `json` FROM users WHERE `id`=?");
 $sql->execute(array($uid));
 $data      = $sql->fetch();
 $arr       = json_decode($data['json'],true);
 $arr[$key] = $val; // Update the value
 $sql=$dbh->prepare("UPDATE `users` SET `json`=? WHERE `id`=?");
 $sql->execute(array(
   json_encode($arr), 
   $uid
 ));
}

где $ uid - это идентификатор пользователя, $ key - ключ JSON для обновления, а его значение упоминается как $ val .

Функция получения значения

function get($uid, $key){
 global $dbh;
 $sql = $dbh->prepare("SELECT `json` FROM `users` WHERE `id`=?");
 $sql->execute(array($uid));
 $data = $sql->fetch();
 $arr  = json_decode($data['json'], true);
 return $arr[$key];
}

где $ key - это ключ массива JSON, из которого нам нужно значение.

Шубин
источник
1
Это не удается в конфликтующих случаях: что, если только что прочитанный json обновляется другим процессом, а затем вы сохраняете его в текущем потоке, перезаписывая его? Вам могут потребоваться блокировки, такие как SELECT FOR UPDATEили управление версиями в данных json.
DhruvPathak
@DhruvPathak Не могли бы вы обновить ответ с помощью, SELECT FOR UPDATEчтобы он был лучше. Я не знаю, как им пользоваться.
Субин
3

Ранняя поддержка для хранения JSON в MySQL была добавлена ​​в выпуск MySQL 5.7.7 JSON labs ( двоичные файлы Linux , исходный код )! Релиз, похоже, вырос из серии пользовательских функций, связанных с JSON, опубликованных еще в 2013 году. .

Эта зарождающаяся нативная поддержка JSON, кажется, движется в очень позитивном направлении, включая проверку JSON на INSERT, оптимизированном двоичном формате хранения, включая таблицу поиска в преамбуле, которая позволяет функции JSN_EXTRACT выполнять двоичный поиск, а не анализировать при каждом доступе. Существует также целый ряд новых функций для обработки и запроса определенных типов данных JSON:

CREATE TABLE users (id INT, preferences JSON);

INSERT INTO users VALUES (1, JSN_OBJECT('showSideBar', true, 'fontSize', 12));

SELECT JSN_EXTRACT(preferences, '$.showSideBar') from users;

+--------------------------------------------------+
| id   | JSN_EXTRACT(preferences, '$.showSideBar') |
+--------------------------------------------------+
| 1    | true                                      |
+--------------------------------------------------+

ИМХО, приведенное выше - отличный вариант использования этой новой функциональности; во многих базах данных SQL уже есть пользовательская таблица, и вместо того, чтобы вносить бесконечные изменения схемы в соответствии с развивающимся набором пользовательских предпочтений, лучше всего иметь один столбец JSON, который находится отдельно JOIN. Тем более, что вряд ли когда-нибудь понадобится запрашивать отдельные элементы.

Хотя это еще рано, команда MySQL сервер делает большую работу по информированию о изменениях на в блоге .

Рич Поллок
источник
2

Я считаю, что хранение JSON в базе данных mysql на самом деле противоречит цели использования СУБД в том виде, в котором она предназначена. Я бы не стал использовать его в каких-либо данных, которые в какой-то момент будут обрабатываться или сообщаться, поскольку это не только добавляет сложности, но и может легко повлиять на производительность в зависимости от того, как они используются.

Однако мне было любопытно, придумал ли кто-нибудь еще возможную причину для этого. Подумал сделать исключение для логирования. В моем случае я хочу регистрировать запросы с переменным количеством параметров и ошибок. В этой ситуации я хочу использовать таблицы для типов запросов и сами запросы со строкой JSON с разными значениями, которые были получены.

В приведенной выше ситуации запросы регистрируются и никогда не обрабатываются и не индексируются в строковом поле JSON. ОДНАКО, в более сложной среде я, вероятно, попытался бы использовать что-то, что больше предназначено для этого типа данных, и сохранить его в этой системе. Как уже говорили другие, это действительно зависит от того, чего вы пытаетесь достичь, но следование стандартам всегда способствует долговечности и надежности!

отметка
источник
2

JSON также является допустимым типом данных в базе данных PostgreSQL. Однако база данных MySQL еще официально не поддерживает JSON. Но это запекание: http://mysqlserverteam.com/json-labs-release-native-json-data-type-and-binary-format/

Я также согласен с тем, что существует множество допустимых случаев, когда некоторые данные лучше сериализовать в строку в базе данных. Основная причина может заключаться в том, что он не запрашивается регулярно и когда его собственная схема может измениться - вы не хотите изменять соответствующую схему базы данных. Вторая причина заключается в том, что когда сериализованная строка поступает непосредственно из внешних источников, вы можете не захотеть анализировать их все и передавать в базу данных любой ценой, пока вы не используете их. Так что я буду ждать, пока новая версия MySQL будет поддерживать JSON, так как тогда будет проще переключаться между разными базами данных.

Черри Цянью Лю
источник
1

Я использую json для записи чего угодно для проекта, фактически использую три таблицы! один для данных в json, один для индекса всех метаданных структуры json (каждая мета кодируется уникальным идентификатором) и один для пользователя сеанса, вот и все. Тест не может быть определен количественно на этом раннем этапе кода, но, например, я использовал просмотры пользователей (внутреннее соединение с индексом), чтобы получить категорию (или что-то еще, как пользователь, ...), и это было очень медленно (очень-очень медленно , использование представления в mysql - не лучший способ). Модуль поиска в этой структуре может делать все, что я хочу, но я думаю, что mongodb будет более эффективным в этой концепции полной записи данных json. В моем примере я использую представления для создания дерева категорий и хлебных крошек, боже мой! так много запросов! сам apache ушел! и, собственно говоря, для этого небольшого веб-сайта я использую PHP, который генерирует дерево и хлебные крошки, извлечение данных выполняется модулем поиска (который использует только индекс), таблица данных используется только для обновления. Если я хочу, я могу уничтожить все индексы и регенерировать их с каждыми данными, а также выполнить обратную работу, например, уничтожить все данные (json) и восстановить их только с помощью таблицы индексов. Мой проект молодой, работает под php и mysql, но иногда я думаю, что использование node js и mongodb будет более эффективным для этого проекта.

Используйте json, если считаете, что можете, просто для этого, потому что вы можете! и забудьте об этом, если это была ошибка; попробуйте сделать хороший или плохой выбор, но попробуйте!

Низкий

французский пользователь

низкий
источник
1
Не поняла. Я изначально не говорю по-английски, но я бы порекомендовал вам использовать точки (.), Запятые (,) и абзацы (клавиша Enter), чтобы систематизировать свои идеи. Тогда, только тогда, попробуйте организовать базу данных ;-)
Диего Янчич
Вы правы, запутанный ответ на самом деле должен быть более явным, показывая пример. Но, если mysql можно заменить на mongoDB, будет более эффективно использовать json (как родной для mongodb), если mysql является обязательным, хорошо, давайте попробуем еще раз через несколько дней!
низкий
1

Я знаю, что это действительно поздно, но у меня была аналогичная ситуация, когда я использовал гибридный подход к поддержанию стандартов РСУБД для нормализации таблиц до определенного момента и последующего сохранения данных в JSON в виде текстового значения после этого момента. Так, например, я храню данные в 4 таблицах, следуя правилам нормализации СУБД. Однако в 4-й таблице для размещения динамической схемы я храню данные в формате JSON. Каждый раз, когда я хочу получить данные, я извлекаю данные JSON, анализирую их и отображаю на Java. До сих пор это сработало для меня, и я по-прежнему могу индексировать поля, которые я преобразовываю в данные json в таблице, нормализованным образом с использованием ETL. Это гарантирует, что пока пользователь работает с приложением, он сталкивается с минимальной задержкой, а поля преобразовываются в удобный формат РСУБД для анализа данных и т. Д.

Prashant
источник
0

Вы можете использовать эту суть: https://gist.github.com/AminaG/33d90cb99c26298c48f670b8ffac39c3

После установки на сервер (просто нужны привилегии root, а не супер), вы можете сделать что-то вроде этого:

select extract_json_value('{"a":["a","2"]}','(/a)')

Он вернется. a 2 Вы можете вернуть что угодно внутри JSON, используя это. Хорошая часть состоит в том, что он поддерживает MySQL 5.1,5.2,5.6. И вам не нужно устанавливать на сервер какой-либо двоичный файл.

На основе старого проекта common-schema, но он все еще работает сегодня https://code.google.com/archive/p/common-schema/

Аминадав Гликштейн
источник
суть теперь 404
neoDev