架构设计

Question

假设您是 GM dba，您必须围绕 GM 模型进行设计

这样做更好吗？

• table_model
  • 类型{凯迪拉克、土星、雪佛兰}

还是这个？

• table_cadillac_model
• table_saturn_model
• table_chevrolet_model

假设一个模型的业务线具有相同的列，并且每个子类型有超过一百万条记录。

编辑：

• 有很多 CRUD
• 有很多处理器密集型报告
• 在任一架构中，都有一个 model_detail 表，其中包含每个模型的 3-5 条记录，并且每个模型的详细信息不同（您不能向 saturn 模型添加凯迪拉克详细信息）
• 开发团队在数据库复杂性方面没有任何问题
• 我不太确定这是一个标准化问题。即使结构相同，它们也可能被视为不同的实体。

编辑：

将结构划分为多个表的原因 - 业务线可能对零件有不同的业务规则 - 每个业务线的 addModelDetail() 可能不同（即使数据格式相同） - 高添加/更新活动 - 使用分区结构而不是单一结构获得更好的性能（我在这里猜测并不确定）？

我认为这是 EAV 问题的一种变体。当作为 EAV 设计提出时，单表结构通常被认为是一个坏主意。当以这种方式提出时，单表结构通常被认为是一个好主意。有趣...

我认为最有趣的答案是有两种不同的结构 - 一种用于 crud，另一种用于报告。我想我会尝试用于报告的连接/扁平视图和用于 crud 的多个表，看看它是如何工作的。

Answer 1

绝对是前一个例子。每当您将新模型添加到您的产品范围时，您是否希望将表添加到您的数据库中？

Answer 2

对于具有大量写入的数据（例如 OLTP 应用程序），最好有更多、更窄的表（例如具有较少字段的表）。由于您只是将少量数据写入不同的表，因此锁争用会减少。

因此，根据您描述的标准，我将拥有的表结构是：

Vehicle
  VehicleType
  Other common fields

CadillacVehicle
  Fields specific to a Caddy

SaturnVehicle
  Fields specific to a Saturn

对于报告，我会在没有标准化结构的完全不同的服务器上拥有一个完全不同的数据库（例如，只有 CadillacVehicle 和 SaturnVehicle 表，其中 Vehicle 表中的所有字段都复制到其中）。

有了适当的索引，即使是 OLTP 数据库也可以在您的 SELECT 中运行，而不管有几千万行。但是，由于您提到存在处理器密集型报告，这就是为什么我会有一个完全独立的报告数据库。

最后一条评论。关于业务规则......数据存储不关心业务规则。如果模型之间的业务规则不同，那真的不应该考虑到您关于数据库模式的设计决策（除了帮助确定哪些字段可以为空及其数据类型）。

Answer 3

使用前者。为专业设置单独的表会使您的代码复杂化，并且不会带来任何其他方式无法实现的优势。它还将大大简化您的报告。

Answer 4

如果表确实有相同的列，那么前者是最好的方法。即使它们有不同的列，您可能仍希望将公共列放在它们自己的表中，并存储类型指示符。

Answer 5

您可以尝试拥有两个独立的数据库。

一个是OLTP（在线事务处理）系统，应该高度规范化，以便数据模型高度正确。报告性能一定不是问题，您可以根据具体情况使用索引/非规范化等处理非报告查询性能。数据模型应尽量与概念模型紧密匹配。

另一个是报告系统，它应该定期从 OLTP 系统中提取数据，并以使报告生成更容易和更高效的方式对数据进行处理和重新排列。数据模型应该不试图与概念模型过于紧密地匹配。您应该能够随时从主数据库中当前的数据重新生成报告数据库中的所有数据。

Answer 6

我会说第一种方式看起来更好。

您是否有理由要采用第二种方式？

第一种方式更好地遵循规范化，并且更接近于大多数关系数据库模式的开发方式。

第二种方式似乎更难维护。

除非有充分的理由采用第二种方法，否则我会采用第一种方法。

Answer 7

根据您给我们的描述，答案是要么。

换句话说，您没有给我们足够的信息来给出一个体面的答案。请描述您希望对数据执行什么样的查询。

[话虽如此，我认为答案将是第一个 ;-) 尽管它们是不同的模型，但在我进行成像时，每个模型的数据可能会非常相似。

但目前这是一个完整的猜测。]

编辑： 鉴于您更新的编辑，我肯定会说第一个。因为他们拥有所有相同的数据，所以他们应该进入同一张表。

Answer 8

在定义“更好”时要考虑的另一件事是最终用户会直接查询这些数据吗？最终用户很难使用高度规范化的数据。当然，这可以通过视图来克服，但在您完成设计时仍然需要考虑。

我同意另外两个人的回答：哪种形式“更好”是主观的，取决于您希望达到的目标。如果您希望实现非常快速的查询，那是一回事。如果您希望实现程序员的高生产力——这又是一个不同的目标，并且可能与快速查询相冲突。

Answer 9

选择取决于所需的性能。 最好的数据库是规范化数据库。但是规范化数据库中可能存在性能问题，然后您必须对其进行非规范化。 “先规范化，非规范化以提高性能”的原则效果很好。

Answer 10

这取决于数据模型和用例。如果您需要报告希望从“模型”中获取数据的查询，那么前者更可取，因为否则（使用后者）您每次添加时都必须更改查询（以包括新表）新模型。

哦，“以前”是指这个选项：

table_model
* type {cadillac, saturn, chevrolet}

Answer 11

@mson 提出了问题"What do you do when a question is not satisfactorily answered on SO?"，这是对该问题现有答案的直接引用。

我为该讨论提供了以下答案，主要是批评提出问题的方式。

---

引用（逐字）：

我昨天看了原来的问题，决定不提供答案。

一个问题是在“通用汽车模型”中使用“模型”一词 - 它引用“雪佛兰、土星、凯迪拉克”作为“模型”。据我了解，这些根本不是模型。它们是“品牌”，尽管它们可能还有一个我不熟悉的业内术语，例如“部门”。模型将是“Saturn Vue”或“Chevrolet Impala”或“Cadillac Escalade”。事实上，很可能会有比这更详细的模型——例如 Saturn Vue 的不同变体。

所以，我不认为起点是很好的框架。我没有批评它；不够吸引人，而且有答案，所以我让其他人尝试。

下一个问题是不清楚您的 DBMS 将存储什么数据。如果您为每个“模型”（“品牌”）存储一百万条记录，那么您要处理哪些类型的数据？潜伏在背景中的是一个不同的场景——真实的场景——你的问题使用了一个不够现实的类比。这意味着答案的“取决于”部分比“这就是如何做”的部分要多得多。可悲的是，要建模的数据的背景信息太少，无法让我们猜测什么可能是最好的。

最终，这将取决于人们对数据的用途。如果信息要向所有不同的方向传播（不同品牌的不同数据结构；车型级别的不同数据结构；不同经销商的不同结构——雪佛兰经销商的处理方式与土星经销商和凯迪拉克经销商不同）经销商），那么集成结构提供的收益有限。如果一切都是一样的，那么集成结构提供了很多好处。

隔离数据是否有法律理由（或好处）？不同品牌在多大程度上是独立的法人实体，共享记录可能是一种责任？是否存在隐私问题，如果单独存储不同品牌的数据，则更容易控制对数据的访问？

如果没有关于所建模场景的更多详细信息，没有人可以给出可靠的一般性答案 - 至少，不会超过投票最多的那个已经给出（或没有给出）的答案。

• 数据建模并不容易。
• 没有足够信息的数据建模是不可能可靠地进行的。

---

我复制了这里的材料，因为它更直接相关。我确实认为要令人满意地回答这个问题，应该给出更多的背景信息。并且可能需要足够的额外上下文来使 SO 成为错误的地方来询问它。 SO 有其局限性，其中之一是它无法处理需要长时间解释的问题。

从 SO 常见问题页面：

我可以在这里问什么样的问题？

当然是编程问题！只要您的问题是：

• 详细而具体
• 写得清晰简洁
• 至少有其他程序员感兴趣

...

我不应该在这里问什么样的问题？

避免提出主观的、争论的或需要长时间讨论的问题。这是一个可以回答问题的地方！

这个问题，IMO，接近“需要扩展讨论”的限制。