令人困惑的复杂性 - 棘手的表加入

Question

我一直在努力使用这一组特定的表格。有三个表（过去是两个，但有必要添加第三个）。表格为Request，PartInfo和Status。客户通过将数据输入表格的表单使用Request。 Status用于我们的服务代理跟踪客户请求的进度。 PartInfo是新表，包含双方访问的公共数据。

诀窍在于，对于每个请求，都有一个对该请求的更改的运行日志，这些更改存储在同一个表中，并通过名为FirstRequestID的自联接键链接到该系列中的原始请求（我将其缩写为FID）。 Status表也是如此。这是我目前设计的基本表结构（注意：如果有更好的方法，改变架构还为时不晚）：

Request          PartInfo          Status
-------          --------          ------
ID               ID                ID
FID              FID               FID
PartInfoID       PartNum           PartInfoID
ProductID        Revision          StatusID
CategoryID       Description       Comments

现在说我想在ASP.NET GridView表中显示有关特定请求的信息（包括部件信息和状态更改）。 “特定请求”由FID标识。

问题： 当我查看请求历史记录或状态历史记录时，如何确保从PartInfo（共享）表中提取正确的信息？换句话说，将这三个表与正确关系联系起来的最佳方法是什么，而没有50个不同的联结表来解释所有异常？

Answer 1

我道歉，但我对这个架构的第一个看法是“这是一团糟”。这些数据需要标准化。不幸的是，这里没有足够的信息来确定如何最好地这样做。根据您的描述和部件名称，我提出了以下想法。

• 主要实体是请求。
• Reqeusts包含产品
• 请求包含类别（除非类别是产品的属性）
• 产品包含零件（除非是包含零件的类别）
• 这意味着请求产品与任意数量的零件相关联（而不是该产品的标准零件组）。
• 状态用于跟踪请求状态随时间的变化（并且不完全取决于产品，类别或部件）

这表示以下表格

REQUESTS
RequestId
DateTimeCreated

PRODUCTS
ProductId
--  Add CategoryId, if it’s a Product attribute

CATEGORIES
CategoryId

REQUESTPRODUCTS
RequestProductId
RequestId
ProductId
DateTimeAdded
--  Add StatusId if a status entry must be made every time a product is requested
--  Note extra surrogate key. ReqeustId + ProductId + DateTimeAdded should be the
--   natural key, unless two identical products can be requested at the same time
--   (in which case add an “Quantity” column)


REQUESTCATEGORIES
RequestId
CategoryId
DateTimeAdded
--  Suorrogate key optional, as it’s not referenced by other tables
--  Drop, if categories are product attributes

PARTS
PartId

REQUESTPRODUCTPARTS
RequestProductId
PartId
--  Add StatusId if a status entry must be made every time a part is requested

STATUS
StatusId
RequestId
DateTimeAdded
Comments

这可以记录下来。您可能最终得到很多“联结”表，但随后您的数据将具有参照完整性，并且准确的SQL查询变得更加简单，更容易编写。