Правильный способ реализации отношения n-to-m

Question

это часть моей базы данных:

Table: Item
Columns: ItemID, Title, Content, Price

Table: Tag
Columns: TagID, Title

Table: ItemTag
Columns: ItemID, TagID

Table: Image
Columns: ImageID, Path, Size, UploadDate

Table: ItemImage
Columns: ItemID, ImageID

Элементы могут иметь более одного изображения, поэтому у меня есть дополнительная таблица «Изображение», и я сопоставляю эти изображения с элементами. Теперь я вижу проблему с этой структурой. Прежде чем я могу добавить изображения, я должен ввести элемент.

Мой вопрос сейчас. Является ли эта структура хорошим способом решения моей проблемы с множеством изображений / тегов для одного элемента?

Спасибо

Answer 1

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

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

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

Answer 2

Это хорошая структура. Таблица сопоставления обычно является наиболее простым способом реализации отношений «многие ко многим».

Вы можете свободно добавлять изображения в таблицу изображений без элемента. Если вы создаете элемент, добавляете к нему изображения, у вас есть несколько вариантов реализации этого:

1. Создание элемента и связанных с ним объектов изображения в памяти как объектов без сохранения, пока пользователь редактирует. Элемент и его изображения сохраняются, когда пользователь закончил.
2. Попросите пользователя сначала добавить изображения, а затем создать элемент из этого набора изображений.
3. Создайте новый элемент (с новым идентификатором) и создайте его по мере создания пользователем. Если пользователь решит отменить, вам придется удалить элемент. Возможно, вам также придется удалить изображения, если они были созданы только для этого элемента.

Я бы пошел (1) - возможно, больше работы для вас, но в результате вы получите более понятную и последовательную систему.

Answer 3

Мой вопрос сейчас. Это структура хороший способ решить мою проблему с много изображений / тегов для одного элемента?

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

Answer 4

Да, это работает.

В вашей настройке:

Элемент имеет много изображений

Товар имеет и принадлежит многим тегам

Изображение содержит один элемент

Теги есть и принадлежит многим Item