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

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

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

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

如果我可以只有一个proofs表和一个comments表,那将是很好的,但根据proofs样类型跟踪图像源和跟踪号码的最佳方法是什么?

我考虑过为electronic_proofsphysical_proofs创建单独的表,但这需要制作一个单独的electronic_proof_comments表和physical_proof_comments表。

另一种选择是拥有一个proofs表,在这种情况下我可以有一个comments表。 但是,正如我所看到的,这将需要三个支持表, proof_typesimage_sourcestracking_numbers

有关最佳方式的想法,还是解决这个问题的更好方法?

正如另一个答案中所提到的,您只需要一个表,并且只会将其中一个字段留空,具体取决于类型。 但是,我的答案的不同之处在于将订单详细信息与certificate相关联,而不是将订单详细信息(或其示例中的订单项)与certificate相关联。 通过这种方式,您可以为每个订单详细信息提供多个校样。

如果我是你,我就会这样设置:

命令

  • OrderID(PK)
  • 客户ID(FK)
  • 等等…

订单详细信息

  • OrderDetailsID(PK)
  • OrderID(FK)
  • PRODUCTID? (FK)
  • 等等…

债权certificate表

  • ProofID(PK)
  • OrderDetailsID(FK)
  • ProofType
  • ImagePath(只是路径,而不是图像)
  • 追踪号码
  • 等等…

评论

  • CommentID(PK)
  • ProofID(FK)
  • 评论
  • 等等…

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

希望这可以帮助! 祝好运!

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

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

我希望certificate类型只是项目的一个属性,跟踪号码和图像源也是如此,对吗?

它类似于某些项目可能有大小的情况,但有些项目没有 – 您只是不填充对该特定类型的项目无关紧要的属性。

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

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

 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 

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