Многие ко многим, но получены из нескольких таблиц - PullRequest
Новая
       19

Многие ко многим, но получены из нескольких таблиц

0 голосов
/ 21 марта 2012

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

Таким образом, у каждого предмета есть таблица (~ 7 таблиц) плюс таблица ящиков.Я хочу создать таблицу BoxContents.Я попытался создать промежуточную таблицу отношений «многие ко многим» с двумя столбцами: один для BoxID и один для ItemBarcode, где BoxID - это FK для PK на таблице Boxes и ItemBarcodeявляется FK для каждого из PK в таблицах Предметов (т.е. я пытался связать несколько таблиц с одним и тем же столбцом).Неудивительно, что это не сработало.Я попытался вставить элемент, и ограничение FK было нарушено для всех, кроме одного из отношений ItemBarcode.

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

Ответы [ 3 ]

7 голосов
/ 21 марта 2012

Вам нужна иерархия категорий (или иерархия классов, иерархия подтипов, иерархия наследования ...):

enter image description here

Существует 3 основных стратегии для реализации иерархии категорий.Если вы выберете «все классы в одной таблице» или «класс на таблицу», то независимо от того, сколько у вас есть видов элементов, вам потребуется только одна таблица «ссылок» для реализации «многие ко многим».отношения.

1 голос
/ 21 марта 2012

Мой первый выбор, если значения ItemBarcode действительно уникальны, будет:

РЕДАКТИРОВАТЬ: Добавлено описание необходимых триггеров.

  • Добавьте триггеры для обеспечения уникальности штрих-кода. (Триггер вставки / обновления в каждой таблице элементов должен проверить, что все (вновь) назначенные штрих-коды не отображаются в других таблицах элементов.)
  • Используйте одну таблицу BoxId / ItemBarcode без отношения FK на стороне штрих-кода, но с триггерами, чтобы гарантировать, что она остается действительной. (Триггер вставки / обновления в таблице сопоставлений должен проверять наличие штрих-кодов в таблицах элементов. Триггер удаления в каждой таблице элементов должен предотвращать или каскадно удалять элементы, которые находятся в таблице сопоставлений. Триггер обновления включен Таблицы элементов необходимо обновить и изменить штрих-коды в таблице сопоставлений. Последние могут быть интегрированы в триггер вставки / обновления в предыдущем пункте.)
  • Рассмотрите возможность использования представления всех элементов для доступа к общим данным ItemBarcode.

Мой второй выбор будет n BoxId / ItemBarcode таблиц для типов элементов n . Просто, но немного занят. Это делает добавление нового типа элемента более сложным, чем нужно.

Я бы не использовал таблицу BoxId / ItemTypeId / ItemBarcode. Он денормализует данные, снова связывая ItemTypeId и ItemBarcode, не позволяет использовать FK на стороне штрих-кода и требует триггеров для обеспечения целостности.

Не бойтесь триггеров. Есть некоторые проблемы, которые они могут решить достаточно эффективно.

0 голосов
/ 21 марта 2012

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

Ваш выбор:

  1. Наличие нескольких столбцов в таблице сопоставлений - по одному для каждой таблицы элементов.
  2. Объединение данных элемента в одну таблицу элементов

Я бы выбрал вариант 2.

...