问我应该如何为这种订单情况设置数据库表

EN

正如在另一个答案中提到的，您只需要一个表，并根据类型将其中一个字段保留为空。然而，我的答案的不同之处在于将订单详细信息与证明相关联，而不是将证明与订单详细信息(或其示例中的订单项)相关联。通过这种方式，您可以为每个订单详细信息提供多个证明。

如果我是你，我会这样设置：

订单

(PK)

• CustomerID (FK)

• Etc...

的

• OrderID

订单列表

• OrderDetailsID (PK)
• OrderID (FK)
• ProductID？(FK)
• Etc...

证明

• ProofID path (仅路径，而不是image)
• TrackingNumber
• Etc...

评论

• CommentID (PK)
• ProofID (FK)
• Comment
• Etc...

将ProofType分解到它自己的表中也可能是明智的，但也可以在没有表的情况下工作。如果要这样做，您需要创建一个ProofType表，并将"Proofs“表中的"ProofType”字段更改为引用新"ProofType“表中的"ProofTypeID”字段的外键。

希望这能有所帮助！祝好运!

我同意@Ricketts (+1)。棘手的部分是在校验表中包含列ImagePath和TrackingNumber，还是将它们规范化到单独的表中。(规范化，因为它们不依赖于主键，它们依赖于主键+证明类型列。)如果这是仅有的两列特定于证明类型的列，那么您可能可以将它们存储在单个表中……但是这个ImagePath让我很紧张，特别是如果它不是一个图像而是一个实际的二进制数据块。出于多种原因，将数据单独存储在它自己的表中，而不是将TrackingNumber移出，这可能是有意义的。

其他注意事项:证明类型之间的比率是多少？性能是如何工作的(特别是当您的数据请求中涉及BLOB时？)在做出最终决定之前，您必须权衡并可能测试这些考虑因素。

我希望证明类型只是物品的一个属性，跟踪号和图像来源也是，对吗？

这类似于某些项目可能有大小，但有些没有-您只是不填充对于特定类型的项目无关紧要的属性。

另外，请注意，对于两个不同的“证明”表，您的订单行项目表现在必须处理两个不同的实体。

像这样的东西对于基本的使用应该是可行的。

ORDERS
 Order ID (PK)

ORDER ITEM
 Order Item ID (PK)
 Order ID (FK)
 Proof ID (FK)

PROOF
 Proof ID (PK)
 Proof Name
 Proof Type
 Tracking Number
 Image Source

COMMENTS
 Comment ID (PK)
 Proof ID (FK)
 Comment Text

如有必要，您可以为校样类型、跟踪编号和图像源创建查找表。这真的取决于你想在多大程度上将现实与关系理论相匹配。