我正在为一个大型库存管理系统实现一个图形数据库，该系统涉及许多不同类型的容器和位置。当创建初始布局时；containedBy"；{boxes}；containedBy"；｛个货架｝。我正在调查的决策涉及预期位置与实际位置。
在我们的库存中，当盒子打开时，预计装在盒子里的物品可能不存在。这与供应商的上游管理有关。当收到清单时，我将在数据库中生成顶点及其边缘，以表示框中的项目。当盒子打开时，我将在接收过程中更新数据库。我想知道的是：用"；expectedContainerBy"；以及"；containedBy"；以表示可能的和实际的容纳，或者具有单个边缘"是否更好；containedBy"；具有"；现在：真/假"；。
我在这里的问题不是从偏好的角度，而是从检索和分析的效率角度。我已经对此进行了一些研究，但不确定通过属性搜索一组边是否比通过边标签搜索更有效，或者数据库是否会因为有这么多边而变得不合理地大。
编辑以进行澄清：数据库是一个Azure CosmosDB图形数据库，使用Gremlin作为我们的查询语言。
不用想太多，我会说我更喜欢"containedBy"；具有布尔值"；现在"；所有物这对我来说很自然，当我想到Gremlin时，你可能会写它来查询这些数据，设计应该保持查询的可读性。
至于效率，这取决于情况。如果你只期望有十个"；containedBy"；每个盒子的边缘，那么我认为在效率方面没有太多需要考虑的。另一方面，数以万计的"；containedBy"；边缘可能是另一回事。此时，您需要考虑图形数据库的功能以及要编写的查询类型。例如，对于一些(大多数？(图，你可能会看到，对于每"1"的数万条边；框"；顶点，有两个单独的标签会更快。或者，如果你使用像JanusGraph这样的具有以顶点为中心的索引的图，你可能会发现在"；现在"；让你得到你想要的性能，同时保持单一"；containedBy"；标签
如果我把这个问题翻过来，我会看到一个Schedule对象。项目链接到日程表，日程表链接到项目过去、现在和将来存储的所有位置。这些Location对象(盒子、架子等(都链接到经过这些位置的所有事物。在项目到达之前，知道它们将要到达，就可以针对其他活动时间表创建时间表。你可以问"；系统"；11点15分哪些货架可以用来存放新到货的货物。
为什么有些蔬菜腐烂得比其他蔬菜快？你可以查看储存历史，看看腐烂的蔬菜是否共享一个共同的储存位置或仓库区域。