Почему не рекомендуется хранить спецификации продукта в одной колонке?

Question

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

, например, «label»: ноутбук, ОЗУ: 8gb».Что не так с этим подходом?Почему я не могу найти веб-статью, которая рекомендует это?Я имею в виду, что не так сложно прийти в голову.

То, что я вижу в Интернете, - это два способа решения этой проблемы:

1 - используйте модель EAV

2- используйте json

Почему бы просто не использовать текстовые пары ключ / значение, как я упоминал

Answer 1

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

Вот несколько причин, по которым вы не хотите этого делать:

• Базы данных имеют плохую функциональность обработки строк.
• Запросы, использующие spec, не могут (вообще) быть оптимизированы с использованием индексов или секционирования.
• Строки имеют большую избыточность, потому что именаповторяется снова и снова (по общему признанию, JSON и XML также имеют эту «функцию»).
• Вы не можете проверять данные для каждой спецификации, используя встроенную функциональность SQL.
• Вы не можете принудительно установить присутствиеопределенных значений.

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

Почему вы не хотите использовать решения, которые вы упоминаете в своем вопросе?

Answer 2

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

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

Если вы храните спецификации таким образом, просто используйте столбец как «черный ящик».Получить всю строку спецификации продукта из базы данных после выбора продукта с использованием обычных столбцов.Затем вы можете взорвать строку спецификации продукта в коде приложения.Вы можете использовать JSON, XML или свой собственный формат.Все, что вы можете манипулировать в коде приложения, является действительным, и это зависит от вас.

Вам также может понравиться пара моих связанных ответов:

• Как спроектироватьтаблица продуктов для многих видов продуктов, где каждый продукт имеет много параметров
• Действительно ли плохо хранить список с разделителями в столбце базы данных? (многие недостатки использования запятой-разделенные списки так же применимы к JSON или XML, или к любому другому формату полуструктурированных данных в одном столбце.)

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

Answer 3

Пары текста (и даже BLOB-объекты JSON) хороши для хранения и отображения, если вам не нужно искать спецификации продукта.Поиск по неструктурированным данным в большинстве баз данных SQL является медленным и ненадежным.Вот почему для вариантов данных обычно используется модель EAV.

Подробнее о структуре можно узнать, изучив Нормальные формы .