小编The*_*uad的帖子

我正在构建一个库存数据库，用于存储 IT 硬件，例如台式计算机、笔记本电脑、交换机、路由器、手机等。我正在使用超类型/子类型模式，其中所有设备都存储在一个表中，以及特定信息被放入子类型表中。我的困境是在以下两种设计之间进行选择：

在上图中，所有设备共享公共子类型。例如，台式计算机和膝上型计算机将在下表中具有记录：Device、NetworkDevice。交换机将在以下位置记录：设备、网络设备。路由器将在以下位置记录：Device、NetworkDevice、WANDevice。我们跟踪位置的任何设备都将在位置记录。我认为此设置的一些优点和缺点：

• 优点：基于通用字段（如主机名或位置 ID）选择记录更容易。
• 优点：没有空字段。
• 缺点：应包含在特定设备的 CRUD 操作中的表并不明显，可能会混淆未来的 DBA。

在底部图表中，所有设备都有自己的子类型（此处未显示更多设备类别）。在这种情况下，很明显哪些表记录被插入或从中选择。台式电脑和笔记本电脑进入电脑等。我认为这个设置的一些优点和缺点：

• 优点：对于子类型的 CRUD 操作使用哪些表是显而易见的。
• 优点：只需使用一张表进行 CRUD 操作。
• 缺点：根据公共子类型字段选择记录需要组合所有表，例如按主机名或位置 ID 搜索。

在这两种情况下，ClassDiscriminator 字段都放置在子类型表中，与 CHECK 约束一起使用以控制可以插入的类型。

是否有关于哪种设计更好的建议，或者这完全是意见问题并取决于数据库的预期目的？

编辑：我有一个关于“NetworkDevice”表的重叠性质的具体问题。该表旨在保存具有主机名和/或 IP 地址的任何设备的网络信息，无论是计算机、交换机还是路由器。该表的重叠性质是否会导致问题，或者以这种方式实现它是否可以？

预先感谢您提供的任何意见。请询问是否需要任何其他信息。

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

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

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

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

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

/sf/ask/653488391/

/sf/ask/87474271/

/sf/ask/389171121/

/sf/ask/462966171/

/sf/ask/35987801/

我正在构建一个跟踪计算机设备和其他硬件设备的库存数据库。在任何设备生命周期的某个时刻，它都会退役并被归档。归档后，需要对其进行跟踪，因为它已从服务中移除并妥善处置。我最初使用活动数据库的精确副本设计了归档机制，该副本将使用从活动数据库中删除时的触发器接收其数据。存档数据库包括所有相关表的副本，因为由于某些外来相关记录不再相关，因此用户不应访问它们以用于新设备，但需要使用存档表进行引用完整性和查询。请记住，此处存档的概念不仅仅是保存历史记录或日志。归档是业务流程的一部分，

下面的 ERD 使用该Inventory.DeviceType表作为示例，其中所有条目和更新都复制到该Archive.DeviceType表中。当用户不再能够输入某种设备类型的库存记录时，它会从Inventory.DeviceType表中删除，但保留在存档表中。此模式用于所有表以确保存档引用有效数据，因此是所有表的副本。

活动表示例（省略其他相关表）

归档表示例（省略其他相关表）

问题

我想弄清楚如果我不知道设备是活动的还是存档的，我将如何查询数据库？例如，如果用户有一个序列号并想查找有关设备的信息，而他们不知道它是否已存档。

选项 1：基于联合创建一个视图？

选项 2：如果第一个查询没有返回任何内容，则查询活动数据库，然后查询存档？

传奇还在继续……

一位同事建议我删除存档数据库并使用软删除方案。我使用这个想法构建了一个模型，然后开始遇到许多其他问题。

以下是使用软删除方案的相同表。

软删除示例

使用此设置，通过将IsArchivedfield设置为 true 并输入ArchivedDate. 我可以轻松查询任何设备是否处于活动状态或已存档。（请忽略该IsActive字段，因为它用于不相关的概念）。

请注意电话子类型表，我必须在其中传播 DeviceID 和 IsArchived 标志的索引，因为活动设备的电话号码必须是唯一的。我也必须对其他子类型表执行此操作。我不知道这是一个好还是坏的设计。

这部分真的让我很困惑......

在外键值可以标记为已删除的情况下，处理软删除的最佳做法是什么。我唯一能想到的就是创建一个例程来搜索与已删除数据相关的所有记录，并为用户创建一个报告来解决差异。例如，如果位置表与设备表相关，并且某些位置被软删除，则设备指的是不再存在且必须移动的位置。

顺便说一下，我使用的是 MS SQL Server 2008 R2，我计划在我的应用程序中使用 Entity Framework 4。我更看重数据库的可维护性而不是性能。

感谢您的阅读。

这是 IT 资产的库存数据库。所使用的模型经过修整，以专注于手头的问题。使用 SQL Server 2008。感谢您抽出时间阅读并提供您可以提供的任何输入。

我的设计包括一个Device表格，其中包含可以输入库存的各种设备。每个设备都有一个布尔标志，CanNetwork表明设备是否具有网络能力，例如，对于大多数计算机CanNetwork = true，对于硬盘驱动器CanNetwork = false；有些打印机是真的，有些是假的。你明白了。

该CanNetwork字段确定创建库存记录时与网络相关的信息是否相关。

设计1

我的第一个设计在表上使用索引Device.DeviceID并Device.CanNetwork在外键约束中使用Asset。

NetworkStatus在此设置中，该表如下所示：

+----------------------------------------------------------------------+
| NetworkStatusID | NetworkStatus  | NetworkStatusDescription          |
|----------------------------------------------------------------------|
| 1               | Connected      | Device connected to network.      |
| 2               | Not Connected  | Device not connected to network.  |
| 3               | Do Not Connect | Do not connect device to network. |
+----------------------------------------------------------------------+

我在Asset …

我正在设计一个跟踪 IT 硬件的资产管理数据库。我决定使用超类型/子类型设计。我现在想跟踪设备更改的历史记录。我想使用单独的历史表，但我无法决定如何跟踪对子类型表所做更改的历史记录。

如果我为每个子类型表使用单独的历史表，我可以通过将它们与超类型历史表连接来重建记录，除非子类型历史表独立于超类型历史表而改变。独立地，我的意思是对超类型表中的数据进行了x 次更新，创建了x 次超类型历史记录，对子类型表进行了y 次更新，创建了y次子类型历史记录。如果在同一天进行更改，我将如何重建记录？

这是对超类型/子类型的良好使用，还是我应该对表进行非规范化？否则，有人可以建议任何方法来解决此类设计的历史问题吗？

使用 MS SQL Server 2008。

这是一个非常简化的 ERD：

这个问题是关于 NULL 的正确使用和对业务逻辑与存储过程的 CHECK 约束的使用。

我有以下表格设置。

我对表进行了标准化以避免使用 NULL。问题是这些表中的一些由于业务流程而相互依赖。有些设备必须经过消毒，有些设备在另一个系统中进行跟踪。所有设备最终都将在处置表中处置。

问题是我需要执行检查，例如如果布尔字段RequiresSantization为真，则在DisposalDate输入Sanitize字段之前无法输入。

此外，如果布尔值为IsTrackedInOther真，则OfficialOutOfService必须先输入字段，然后DisposalDate才能输入。

如果我将所有这些列合并到Archive.Device表中，那么我将拥有 NULL 字段，但我将能够使用 CHECK 约束管理所有业务规则。

另一种方法是让表保持原样，并通过从表中选择以检查记录是否存在，然后抛出适当的错误来管理存储过程中的业务逻辑。

这是可以适当使用 NULL 的情况吗？布尔领域IsTrackedInOther 和RequiresSanitization基本赋予意义的NULL字段。如果IsTrackedInOther是，false则设备未在其他系统中跟踪SectionID并且SpecialDeviceCode为 NULL，我知道它们应该为 NULL，因为它未在其他系统中跟踪。同样，OfficialOutOfServiceDate和OOSLogPath我知道会是NULL藏汉，并且DisposalDate可以随时进入。

如果IsTrackedInOther是true，那么SectionID和SpecialDeviceCode将是必需的，如果OfficialOutOfServiceDate和OOSLogPath是NULL，那么我知道它们还没有被正式从该系统中删除，因此DisposalDate在输入它们之前不能有a 。

所以这是一个问题

单独的表/无 NULL/在存储过程中强制执行规则

对比

在 CHECK 约束中组合表/NULLs/强制规则。

我知道在图片中使用 NULL …