2013-08-11 1 views
2

Я хотел бы сохранить значения для каждой спецификации элемента, но с возможностью добавления новых спецификаций во времени без изменения моей структуры базы данных.Можно ли использовать JSON для хранения данных в базе данных mysql?

То есть PHP массив, в конце концов, что будет выглядеть примерно так:

$vase['features'] = array('weight'=>10,'height'=>100); 

Но кто мог очень хорошо иметь пятьдесят ключи в течение нескольких дней.

$vase['features'] = array('weight'=>10,'height'=>100,'price'=>12,'time'=>1821,...); 

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

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

+1

Возможно, вы захотите взглянуть на [EAV] (http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model). Хотя это все равно будет трудно, но немного меньше, чтобы отфильтровать результаты, если они настроены правильно. Я хочу добавить, что это называется «анти-шаблон». И что у меня есть только небольшой опыт, но, черт возьми, я рад, что нашел другое решение. – AmazingDreams

+0

Я должен был добавить это прямо: я долго и долго думал о сущности, которые мне приходилось хранить, и сумел сгруппировать их и создать таблицы для этих групп. Я написал несколько PHP для ленивой загрузки «расширенного объекта» вместе с «основным объектом» и доступа к его свойствам через главный объект (без '$ main-> sub-> property'). Моя удача, однако, заключалась в том, что «подобъектам» никогда не приходилось смешивать и показывать приказанным некоторым свойством, которое было только на одном из них. – AmazingDreams

ответ

2

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

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

Как я хотел бы сделать это состоит в следующем:

  • таблица со списком функций, которые можно расширить с легкостью
  • таблица, которая содержит идентификатор содержимого (или продукт), идентификатор функции и значение функции.

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

+0

Вы описываете [EAV] (http: //en.wikipedia.org/wiki/Entity% E2% 80% 93attribute% E2% 80% 93value_model) – AmazingDreams

+1

Я думал об этом, что на самом деле похоже на то, что я использую для хранения разрешений на доступ к подфорумам. Мне было интересно, хотя, если бы это было немного «опасно» ... Я должен признать, что я мало знаю о хранении данных, хотя это может привести к тысячам записей довольно быстро ... Я имею в виду, конечно, будет достаточно места, но не приведет ли это к важной задержке в запросах mySQL? –

+0

О, это будет. Представьте себе мир, в котором вы храните строки, целые числа, поплавки, булевы и тексты, и вы должны были заказать все это по стоимости? – AmazingDreams

0

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

0

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

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