相关疑难解决方法(0)

介绍

为了让这个问题对未来的读者有用，我将使用通用数据模型来说明我面临的问题。

我们的数据模型由 3 个实体组成，它们应标记为A、B和C。为了简单起见，它们的所有属性都将是int类型。

实体A具有以下属性：D,E和X;

实体B具有以下属性：D,E和Y;

实体C具有以下属性：D和Z；

由于所有实体共享公共属性D，我决定应用类型/子类型设计。

重要提示：实体是互斥的！这意味着实体是 A 或 B 或 C。

问题：

实体A和B还有另一个共同的属性E，但是这个属性并不存在于实体中C。

题：

如果可能的话，我想使用上述特性来进一步优化我的设计。

老实说，我不知道如何做到这一点，也不知道从哪里开始尝试，因此这篇文章。

我正在构建一个库存数据库来存储企业硬件信息。数据库跟踪的设备范围包括工作站、笔记本电脑、交换机、路由器、移动电话等。我使用设备序列号作为主键。我遇到的问题是这些设备的其他属性各不相同，我不希望库存表中有与其他设备无关的字段。下面是指向部分数据库的 ERD 的链接（未显示某些 FK 关系）。例如，我正在尝试设置它，因此无法将具有工作站设备类型的设备放入电话表中。这似乎需要使用大量触发器来验证设备类型或类，并且随时会跟踪具有不同属性的不同设备的新表；

我研究了设置可以映射到序列号的属性表，但这将允许将不适用于设备类型的属性分配给设备，例如，如果有人愿意，可以将电话号码属性分配给工作站. 我在这个网站上找到了一个解释，给出了以下结构：

如果属性都适用于我正在存储的项目，那么这种结构会很好用。例如，如果数据库只存储手机，则属性可能是触摸屏、触控板、键盘、4G、3G ……任何东西。在这种情况下，它们都适用于手机。我的数据库将具有主机名、电路类型、电话号码等属性，这些属性仅适用于特定类型的设备。

我想对其进行设置，以便只有适用于给定设备类型的属性才能分配给该类型的设备。有关如何设置此数据库的任何建议？我不确定这是否是一对一关系的正确使用，或者是否有更好的方法来做到这一点。预先感谢您抽出时间来研究这个问题。

这是我阅读的其他一些主题。他们给了我一些很好的见解，但我认为它们并不适用：

/sf/ask/653488391/

/sf/ask/87474271/

/sf/ask/389171121/

/sf/ask/462966171/

/sf/ask/35987801/

在以下场景中寻找与优化设计相关的一些建议。

1. 有一个 Cases 表（代表库存的情况）
2. 有一个 LocationInventory 表（代表有库存的位置）
3. 然后我有一个或多个 InventoryNeed 表（这是问题的关键），需要考虑案例和位置。

选项A：

一张表有 2 个外键列，其中将填充一个且仅一个外键。

表：库存需求

1. 案例 ID (FK)
2. 位置库存 ID (FK)
3. 所需数量

在这种情况下，CaseId 或 LocationInventoryId 将为 null，而另一个已填充。

选项B：

每种需求类型有两个表，经常通过 UNION 来获取摘要数据。

表：库存需求案例

1. 案例 ID (FK)
2. 所需数量

表：库存需求地点

1. 位置库存 ID (FK)
2. 所需数量

选项C：

一张没有参照完整性的表。

表：库存需求案例

1. NeedType（案例或位置的值）
2. NeedId（表示基于 NeedType 的 Case 或 LocationInventory 的主键）。
3. 所需数量

最终获胜者是？我可能会将范围缩小为 A 或 B 以确保数据完整性......但不确定哪个是最好的。或者也许有一个选项 D（例如创建具有公共列的基表......）

更新的场景

当我昨晚发布此内容时，我只考虑下游，但也存在对这些相同表的上游依赖关系。我画了一些图，希望能更好地解释它。随着这个出现，选项 B 开始爆炸所涉及的表的数量，在阅读了这个 SE 答案之后……我现在更倾向于 A。

下面的图片。然后红色代表库存需求，绿色代表满足这些需求的库存来源。黄色是当前的问题......如何有效地连接红色和绿色。

选项 A 图片 - 有更多解释和背景

选项 B - 为清楚起见删除了上下文

TL;DR：我如何在这么多表之间建立多对多关系，它是否可行/推荐？

• 每种体型都有自己的表格
• 每个车身类型表中的每辆车都可以有几个特征

正如您从我的“架构”中看到的，每辆车都可以有多个功能，但我需要将功能表连接到几个车身类型表（多对多关系）。我已经考虑了几天，但我仍然不确定如何实现这一点。

为什么所有体型都在单独的表格中？这似乎遵循规范化规则，它还应该加快查询速度，因为我永远不必一次查询多种主体类型。

有可能还是我应该重新考虑一下？我应该制作另一张关于车身类型的表格并将所有汽车组合起来吗？我希望最多有 100 万个条目（所有身体类型相结合）。读取将比写入多得多。