Требуемая структура зависит от типа отношения: один-ко-многим, много-к-одному или много-ко-многим (M2M).
Для одного-ко-многим внешний ключ (FK) на стороне «многих» связывает многие элементы с «одной» стороной. Обратное верно для многих-к-одному.
Для многих-ко-многим (M2M) вам нужна промежуточная реляционная (или соединительная) таблица точно так же, как вы предлагаете. Это позволяет вам «повторно использовать» обе категории и свойства в любых комбинациях. Однако это немного больше SQL - требуется 2 JOIN.
Если вы ищете производительность, то использование FK для первичных ключей (PK) будет очень эффективным, а запросы довольно просты. Использование JSON, по-видимому, потребовало бы, чтобы вы анализировали PHP и строили «на лету» второй запрос, который бы умножал вашу работу по кодированию и тестирование, передачу данных, накладные расходы процессора и ограничение масштабируемости.
В вашем случае я предполагаю, что как «графические карты», так и «жесткие диски» могут иметь, например, «размер памяти» плюс другие свойства, поэтому вам понадобится реляционная таблица M2M, как вы предлагаете.
До тех пор, пока ваши ключи проиндексированы (какие PK-ы), ваш JOIN в эту реляционную таблицу будет очень быстрым и эффективным.
Если вы используете CONSTRAINT с вашими отношениями, они гарантируют вам целостность данных: вы не можете удалить категорию, к которой привязано свойство. Это хорошая функция в долгосрочной перспективе.
Сотни и тысячи записей - это крошечное количество для MySQL. Вы использовали бы эту технику даже с миллионами записей. Так что не беспокойтесь о размере.
Базы данных RDBMS предназначены специально для этого, поэтому я бы рекомендовал использовать собственные функции, кроме как попробовать сделать это самостоятельно в JSON. (если мне не хватает какой-то новой функции JSON MySQL!)
* После публикации этого сообщения я действительно наткнулся на a new JSON MySQL feature. Кажется, из быстрого чтения вы можете реализовать всевозможные новые структуры и отношения, используя JSON и виртуальные ключи столбцов, возможно, устраняя необходимость в таблицах соединений. Это, вероятно, приведет к размыванию линии между MySQL как RDBMS и NoSQL.
Wow Я только что узнал что-то новое. Я не знал о CASCADE. Спасибо за помощь. Я воспользуюсь вашим решением. –