我正在尝试在Access 2016中创建一个关系数据库,以保持办公室中存储的物品清单。它们中的大多数都放在某种盒子中,所以我决定每个记录应该是Container
,可以是盒子,袋子或装有多个物品的物理容器,也可以只是一个不包含物品。例如,坐在架子上的打印机仍将被视为Container
,但是容器的类型将为“无”。装满金砖四箱的盒子的类型为“盒子”,而它们的每个项目都将在单独的表中枚举。
每个Container
内可以有多个Item
-例如一个盒子里可能装有一束笔,一条HDMI电缆和一张名片夹。这三个项目在Item
表中都有自己的记录,并具有描述该项目的各种属性(品牌,颜色,数量(如果存在多个相同项目,则为数量等)。)每个Item
都与其{ Container
的{1}}-关系是一对多的。
我设想的这种设计的问题是数据冗余-因为容器既可以是文字容器,也可以只是一个项目(例如打印机),在后一种情况下,我必须命名父级ContainerID
“打印机”,并将子项Container
命名为“打印机”。或者,我可以将Item
的名称字段保留为空白,以便仅命名Item
,但是我不确定在数据库设计中是否认为这是不好的做法。
另一个问题是我的设计不能整齐地容纳子容器-例如如果在一个更大的盒子中也有一个袋子,里面还有其他东西,我只需要提供一个描述性标题“包含笔,电缆的袋子……”我无法想象有任何方法可以使我的数据库递归所以我想不出任何解决方案。考虑到我正在使用的包装盒的大小,我会经常遇到这种情况。
所以我的问题是两个:
1)我正在尝试实现的解决方案是否有一种解决方法,可以让我将容器整齐地存储在容器中?
2)对于我要完成的工作,是否有更有效的数据库设计?
答案 0 :(得分:2)
您的问题肯定满足了许多接近投票的选项,并且也很可能会主要吸引基于意见的答案,因为我敢肯定,有很多方法可以解决此问题……不过,一种可能的“递归”解决方案可能是以下内容:
创建一个Items
表,其中的每个记录都包含一个唯一的标识符ItemID
作为主键,以及该项的各种属性(例如,说明,大小,颜色,值,类型等),而且还包含一个名为ContainerID
或Container
的外键字段,可以使用ItemID
表本身中另一项的Items
填充:
通过这种方式:
ContainerID
字段值,表示构成“ bric-a-brac”的项目包含在同一框中。ContainerID
引用了Items
表中的另一个项目,因此容器也可能具有ContainerID
值,从而可以表示无限级别的嵌套容器:这个问题与表示this question中探讨并回答的管理层次结构(或者实际上是任何层次结构)的问题非常相似。