У меня тоже похожая «проблема» на руках. Я разрабатываю небольшую базу данных продуктов, которая включает тегирование, а также присваивает тегам значение (например, tagname: color, value: green).
Две основные таблицы - это позиции (I) и статьи (A). Предметы - это реальные физические предметы, а предметы извлекаются из предметов. Статьи - это то, что может отображаться на веб-сайте, а предметы - те, которые хранятся на складе.
Небольшим примером таких отношений могут быть автомобильные запчасти. Радиатор с известными размерами и другими данными может на самом деле соответствовать многим различным моделям и маркам, поэтому элемент, используемый для повторного представления радиатора, относится к нескольким изделиям, которые указывают, что радиатор может соответствовать.
С другой стороны, у нас может быть два разных радиатора для одной модели, одна из которых - заводская версия, а другая - только что восстановленная. В таком случае есть два пункта, относящиеся к одной и той же статье.
Итак, у меня и А отношения N: M.
Предметы и статьи имеют определенные свойства. Например, элемент радиатора может иметь такие данные, как состояние, материал, вес, высота, ширина и толщина.
В статье также содержится некоторая базовая информация, такая как марка, модель, год выпуска, двигатель и т. Д., Но могут также потребоваться некоторые специальные данные, такие как модель шасси, тип трансмиссии или что-то еще, например два разных типа фитингов, которые использовались на одной и той же модели.
Поскольку два элемента могут ссылаться на одну статью, это означает, что я не могу просто помечать статьи. Маркировать статью обоими значениями условия просто глупо, с другой стороны, маркировка одного элемента несколькими экземплярами модели, марки или какого-либо специального требования также не является хорошей идеей. _существуют два типа свойств: первый указывает на что-то, а второй - на то, что он подходит.
Теги не обязательно должны иметь значение, они могут просто действовать как обычный тег, назначенный объекту.
Радиаторы являются лишь примером простого продукта. Мы могли бы также поместить некоторые части компьютера или одежду в нашу базу данных. Это означает, что мне нужно иметь возможность размещать разные «теги» на двух разных объектах, I и A.
Мне нужно иметь возможность осуществлять поиск статей в интернет-магазине. Допустим, я использую древовидную навигацию, где у меня есть категория «Используемые радиаторы Nissan».
Поиск будет включать в себя поиск как статей, так и предметов, статьи имеют тег Model: Nissan, а товары имеют тег Condition: Used.
Конечно, когда пользователь просматривает статью, он действительно видит все элементы, связанные со статьей.
Одним из решений, над которым я размышляю, является проект базы данных треугольников, в котором есть общая таблица, называемая тегами для всех свойств и тегов.
У нас есть элементы таблицы (I), статьи (A) и теги (T)
Они соединены отношениями N: M:
I2A присоединяет предметы к статьям.
T2I присоединяет теги к элементам и может также хранить значение для тега или свойства.
T2A присоединяет теги к статьям и может также хранить значение для тега.
На бумаге этот 6-табличный дизайн для решения этой проблемы выглядит довольно хорошо, но у меня болит голова при формировании достойного запроса, где я могу выбрать статьи, которые соответствуют набору различных тегов и их значениям, например:
Состояние = Восстановленное, Марка = Nissan
То, что я хочу сделать, это что-то вроде www.summitracing.com. Выберите Отделы слева внизу «Магазин», выберите любую категорию, и вы увидите, как им удалось придать элементам некоторые свойства. У них есть размер двигателя для большинства применений, но при поиске ободов у них также есть свойство для ширины.
Буду признателен за любые отзывы по этому поводу, я начинаю бить мертвецов, пытаясь спроектировать это.