Есть ли более эффективный способ хранения контейнеров объектов в Access?

Question

Я пытаюсь создать реляционную базу данных в Access 2016, чтобы сохранить список предметов, хранящихся в нашем офисе.Большинство из них находятся в каких-то коробках, поэтому я решил, что каждая запись должна быть Container, которая может быть либо коробкой, сумкой, либо физическим контейнером, в котором хранится несколько предметов, или это может быть просто один незакрепленный предмет,Например, принтер, стоящий на полке, все равно будет считаться Container, но тип контейнера будет «Нет».Принимая во внимание, что у коробки, полной bric-a-brac, будет тип "Коробка", и каждый из их пунктов будет перечислен в отдельной таблице.

Каждый Container может иметь более одного Item в пределах- Например, в коробке может быть пачка ручек, кабель HDMI и визитница.Все три элемента будут иметь свою собственную запись в таблице Item с различными свойствами, описывающими элемент (марка, цвет, количество, если имеется более одного идентичного элемента и т. Д.). Каждый Item связан со своим ContainerContainerID - отношение один ко многим.

Проблема, которую я рассматриваю в этом проекте, заключается в избыточности данных - поскольку контейнер может быть как буквальным контейнером, так и просто одним элементом (например, принтером), вВ последнем случае мне нужно было бы назвать родительский Container «Принтер», а также назвать дочерний Item «Принтер».Или я мог бы оставить поле имени для Item пустым, чтобы было названо только Container, но я не уверен, считается ли это плохой практикой в ​​проектировании баз данных.

Другая проблема заключается в том, чтомой дизайн не совсем подходит для субконтейнеров - например, если внутри большой коробки есть сумка, в которой есть и другие вещи, мне просто придётся дать описательное название «Сумка с ручками, кабелями ...»Я не могу представить, что есть какой-то способ сделать мою базу данных рекурсивной, поэтому я не могу придумать никакого решения для этого.И учитывая размер ящиков, с которыми я работаю, я часто сталкиваюсь с этим сценарием.

Поэтому у меня два вопроса:

1) Есть ли обходной путь для решения, которое япытаясь реализовать это, что позволяет мне аккуратно хранить контейнеры в контейнерах?

2) Есть ли более эффективный дизайн базы данных для того, что я пытаюсь достичь?

Answer 1

Ваш вопрос, безусловно, удовлетворяет многим из доступных вариантов закрытого голосования и, вероятно, также привлечет в первую очередь основанные на мнении ответы, поскольку я уверен, что есть много способов подойти к этому ... тем не менее, одно из возможных «рекурсивных» решенийможет быть следующим:

Создать таблицу Items, в которой каждая запись содержит уникальный идентификатор ItemID в качестве первичного ключа и различные свойства элемента (например, описание, размер, цвет, значение, типи т. д.), но также включает поле внешнего ключа, называемое ContainerID или Container, которое может быть заполнено ItemID другого элемента в самой таблице Items:

Таким образом:

• Ваш пример принтера уже не контейнер, а просто элемент с соответствующими свойствами и без лишних записей.
• Многие элементы могут иметь одно и то же значение поля ContainerID, представляющее элементы, составляющие ваш 'bric-a-brac', содержащиеся в одном и том же блоке.
• Поскольку ContainerID относится к другому элементу в таблице Items, контейнер также может иметь значение ContainerID, что позволяет вам представлять бесконечный уровень вложенных контейнеров:

Эта проблема очень похожа на проблему представления иерархии управления (или даже любой иерархии), как было рассмотрено и дано в этом вопросе .