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

Question

我正在为一家印刷公司构建一个Web应用程序，并且正在尝试为我的数据库确定最佳设计。

我有一个orders表。每个order都有很多证明。但是，有两种不同的证明：电子证明和物理证明。此外，如果它是电子证据，我需要存储图像源，如果它是物理证据，我需要存储跟踪号码。

每个证据都有很多与之相关的评论。

如果我可以只有一个proofs表和一个comments表，那会很好，但根据证据类型跟踪图像源和跟踪号的最佳方法是什么？

我考虑为electronic_proofs和physical_proofs创建单独的表，但这需要创建一个单独的electronic_proof_comments表和physical_proof_comments表。

另一种选择是拥有一个proofs表，在这种情况下，我可以拥有一个comments表。但是，正如我所看到的那样，这需要三个支持表，proof_types，image_sources和tracking_numbers。

有关最佳方式的想法，还是解决此问题的更好方法？

Answer 1

正如另一个答案中所提到的，您只需要一个表，并且只会将其中一个字段留空，具体取决于类型。但是，我的答案的不同之处在于将订单详细信息与证明相关联，而不是将订单详细信息（或其示例中的订单项）的证据联系起来。这样做可以让您为每个订单明细提供多个证明。

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

订单

• OrderID（PK）
• CustomerID（FK）
• 等等...

ORDERDETAILS

• OrderDetailsID（PK）
• OrderID（FK）
• 的ProductID？ （FK）
• 等等...

校样

• ProofID（PK）
• OrderDetailsID（FK）
• ProofType
• ImagePath（只是路径，不是图像）
• TrackingNumber
• 等等...

COMMENTS

• CommentID（PK）
• ProofID（FK）
• 注释
• 等等...

将ProofType分解为自己的表可能也是明智的，但是没有。如果您这样做，您将创建一个ProofType表，并将“Proofs”表中的“ProofType”字段更改为引用新“ProofType”表中“ProofTypeID”字段的外键。

希望这有帮助！祝你好运！

Answer 2

我同意@Ricketts（+1）。棘手的部分是在Proof表中是否有列ImagePath和TrackingNumber，或者将它们标准化为单独的表。 （规范化，因为它们不依赖于主键，它们依赖于主键+证明类型列。）如果这些是唯一两个特定于证据类型的列，那么您可能 确定将它们存储在单个表中......但是ImagePath让我感到紧张，特别是如果它不是图像而是实际大量的二进制数据。由于一些原因，将这些数据单独存储在自己的表中可能是有意义的，但也不会将TrackingNumber移出。

其他考虑因素：证明类型之间的比例是多少？性能如何发挥作用（特别是如果您的数据请求中涉及BLOB？）在做出最终决定之前，您必须权衡并测试这些注意事项。

Answer 3

我希望证明类型只是项目的一个属性，跟踪号码和图像源也是如此，对吗？

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

另外，请注意，使用两个不同的“校样”表格，您的订单行项目表现在必须处理两个不同的实体。

这样的东西应该可以用于基本用途......

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

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