2013-03-28 3 views
0

Мне нужно сохранить массив данных в MySQL. Однако массив не фиксирован по длине.Сохранение JSON для mySQL с помощью PHP

Массив может быть что-то вроде:

array(key1 => value1) 

или как

array(key1 => value1, key2=> value2) 

и так далее.

Если это был массив с фиксированной длиной, тогда JOIN мог бы решить проблему. Я думал о сохранении его в виде строки JSON

таблица данных будет, как:

id -- context -- content (JSON Str) 

Является ли это хорошая идея? есть ли лучшие способы сделать это?
Спасибо

ответ

3

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

data [table] 
- id 
- context 

data_items [table] 
- data_id [foreign_key] 
- key 
- value 

Вставьте столько записей data_items, сколько у вас есть в массиве, ссылающихся на одну запись данных.

+1

Это очень хорошая идея, определенно опрятная. – UnLoCo

+0

, кроме того, потребуется другая таблица, чтобы действовать как посредник между контекстом и ключами, чтобы иметь возможность указать, какой ключ принадлежит какой строке. – UnLoCo

+1

Это не обязательно, data_id уже предоставляет это. Если вы изо всех сил пытаетесь собрать все это вместе, отправьте новый вопрос с некоторыми примерами данных, которые необходимо организовать. – jszobody

1

Да, это хорошая идея для хранения данных массива в JSON. Это более портативный, который сериализует и, по моему опыту, лучше справляется с символами UTF-8.

FTR Обычно я стараюсь не хранить огромное количество «содержимого» данных в базе данных, но выбираю какое-то хранилище файлов для хранения иглы/сена, например MongoDB.

+0

Переносимость не является проблемой. UTF-8 не является проблемой. В любом случае оба могут быть ошибочными, с или без строк JSON. – Sven

+0

Переносимость может быть проблемой, если для доступа к данным «контента» используется не PHP-код. И, как я упоминал в своем посте, JSON, по моему опыту, лучше обрабатывает символы utf-8, чем сериализует. ОП не упоминает, какой тип данных будет храниться в массиве, что путает, b/c другие предполагают нормализацию базы данных, где я предполагал хранение данных. –

+1

Ну, альтернативой является правильное сохранение данных в нескольких строках и их подключение через идентификационные ссылки. Это будет работать с любой кодировкой, любым языком программирования. – Sven

1

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

Обычно лучше нормализовать данные со второй таблицей. Или переключитесь на решение базы данных NOSQL.

1

Вы можете хранить сериализованные данные в формате сериализации, таком как формат сериализации PHP или JSON. Мой единственный вопрос заключается в том, нужно ли вам получать доступ к любым данным в этом сериализованном массиве (т. Е. Запрос к этим данным). Если вы всегда будете запрашивать какой-либо идентификатор, это должно работать нормально. Однако, если вам действительно нужно работать с этими данными в базе данных, вы можете рассмотреть решение NoSQL для работы с неструктурированными данными.

Смежные вопросы