gpt4 book ai didi

database - 设计一个 'Order' 模式,其中有不同的产品定义表

转载 作者:太空狗 更新时间:2023-10-30 01:47:02 25 4
gpt4 key购买 nike

这是我多年来在多个地方看到的场景;我想知道是否有其他人遇到过比我更好的解决方案...

我公司销售的产品数量相对较少,但我们销售的产品高度特化(即,为了选择给定的产品,必须提供大量相关详细信息)。问题在于,虽然选择给定产品所需的数量细节相对恒定,但产品之间所需的种类细节差异很大。例如:

产品 X 可能具有(假设)这样的识别特征

  • '颜色',
  • “ Material ”
  • “平均故障时间”

但是产品Y可能有特点

  • '厚度',
  • '直径'
  • “电源”

创建同时使用产品 X 和产品 Y 的订单系统的问题(无论如何,其中之一)是订单行必须在某些时候引用它“销售”的内容。由于产品 X 和产品 Y 在两个不同的表中定义 - 并且使用宽表方案对产品进行非规范化不是一种选择(产品定义非常深) - 很难找到一种清晰的方式来定义订单行订单输入、编辑和报告的实用方式。


我过去尝试过的事情

  • 创建一个名为“Product”的父表,其中包含 Product X 和 Product Y 共有的列,然后使用“Product”作为 OrderLine 表的引用,并创建一个以“Product”作为表之间主端的 FK 关系对于产品 X 和产品 Y。这基本上将“产品”表作为 OrderLine 和所有不同产品表(例如产品 X 和 Y)的父级。它适用于订单输入,但会导致订单报告或编辑出现问题,因为“产品”记录必须跟踪它是什么类型的产品,以确定如何将“产品”加入其更详细的子产品,产品 X 或产品Y. 优点:关键关系得以保留。 缺点:在订单行/产品级别进行报告和编辑。
  • 在订单行级别创建“产品类型”和“产品 key ”列,然后使用一些 CASE 逻辑或 View 来确定该行所指的定制产品。这类似于第 (1) 项,但没有通用的“产品”表。我认为这是一个更“快速和肮脏”的解决方案,因为它完全消除了订单行及其产品定义之间的外键。 优点:快速解决。 缺点:与第(1)项相同,加上失去了RI。
  • 通过创建通用标题表并为自定义属性使用键/值对 (OrderLine [n] <- [1] Product [1] <- [n] ProductAttribute) 来统一产品定义。 优点:关键关系得以保留;产品定义没有歧义。 缺点:报告(例如检索产品及其属性列表)、属性值的数据类型化、性能(获取产品属性、插入或更新产品属性等)

如果有人尝试过不同的策略并取得了更大的成功,我当然很想听听。

谢谢。

最佳答案

如果您想保持数据完整性,并且您的产品类型相对较少并且很少添加新产品类型,那么您描述的第一个解决方案是最好的。这是我会根据您的情况选择的设计。只有当您的报告需要特定于产品的属性时,报告才是复杂的。如果您的报告只需要通用产品表中的属性,那很好。

您描述的第二个解决方案称为“多态关联”,但效果不佳。您的“外键”不是真正的外键,因此您不能使用 DRI 约束来确保数据完整性。 OO 多态性在关系模型中没有类似物。

您描述的第三个解决方案涉及将属性名称存储为字符串,是一种称为“实体-属性-值”的设计,您可以看出这是一个痛苦且昂贵的解决方案。没有办法确保数据完整性,没有办法使一个属性不为空,没有办法确保给定的产品具有一组特定的属性。无法根据查找表限制一个属性。许多类型的聚合查询在 SQL 中变得不可能执行,因此您必须编写大量应用程序代码来执行报表。仅在必要时才使用 EAV 设计,例如,如果您有无限数量的产品类型,则每一行的属性列表可能不同,并且您的架构必须经常适应新的产品类型,而无需更改代码或架构。

另一种解决方案是“单表继承”。这使用了一个非常宽的表,每个产品的每个属性都有一个列。在给定行上与产品无关的列中保留 NULL。这实际上意味着您不能将属性声明为 NOT NULL(除非它在所有产品共有的组中)。此外,大多数 RDBMS 产品对单个表中的列数或一行的总宽度(以字节为单位)有限制。因此,您可以通过这种方式表示的产品类型数量有限。

存在混合解决方案,例如,您可以通常将通用属性存储在列中,但将特定于产品的属性存储在 Entity-Attribute-Value 表中。或者,您可以在 Products 表的 BLOB 列中以其他结构化方式(如 XML 或 YAML)存储特定于产品的属性。但是这些混合解决方案受到了影响,因为现在必须以不同的方式获取某些属性

针对这种情况的最终解决方案是使用语义数据模型,使用 RDF 而不是关系数据库。这与 EAV 有一些相同的特征,但它更雄心勃勃。所有元数据都以与数据相同的方式存储,因此每个对象都是自描述的,您可以像查询数据一样查询给定产品的属性列表。存在特殊产品,例如JenaSesame ,实现此数据模型和不同于 SQL 的特殊查询语言。

关于database - 设计一个 'Order' 模式,其中有不同的产品定义表,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/120907/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com