Хранение массивов в базе данных

Question

Мне интересно, действительно ли это хорошая практика для хранения массивов в базе данных? Я склонен использовать json_encode вместо serialize, но мне было просто интересно, хорошая ли это идея. Если нет, то я могу внести небольшие изменения и просто взорвать массив запятой.

Answer 1

Нет, это ужасная практика.Пожалуйста, воздержитесь от вставки сериализованных данных CSV, JSON *, serialize() или ЛЮБОГО вида в реляционную базу данных.Денормализация почти всегда является плохой идеей - не делайте этого, если вы действительно не знаете, что делаете, или не начнете задавать такие вопросы, как: это , это , это , это , ...

При этом вы теряете или это серьезно ограничивает вашу способность:

• Использовать JOIN с.
• Найти или изменить конкретный элемент
• Обеспечить ссылочную целостность
• Выгода от использования индекса
• И это также тратит пространство

Это может звучать педантично, но видеть, как люди делают это, - одна из моих любимых мозолей - особенно в свете множества вопросов, задаваемых по SO, которых можно было бы избежать, если бы они поступили правильно.

Вот *1032* 1035 ** Хотя в некоторых базах данных SQL есть встроенная поддержка JSON, это правильный путь *1032* для создания отношений один ко многим и ко многим ко многим.часто лучше реструктурировать ваши данные так, чтобы вам это не понадобилось

Answer 2

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

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