模式设计

Question

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

这样做更好吗？

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

或这个？

• table_cadillac_model
• table_saturn_model
• table_chevrolet_model

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

编辑：

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

编辑：

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

我认为这是EAV问题的一种变体。 如果将其摆放在EAV设计中，则通常认为单表结构是一个坏主意。 当以这种方式摆姿势时，通常将单个表结构投票给一个好主意。 有趣...

我认为最有趣的答案是具有两种不同的结构-一种用于原始数据，另一种用于报告。 我想我将尝试使用级联/展平视图进行报告，并使用多个表进行分类，看看它是如何工作的。

Answer 1

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

Answer 2

对于具有大量写入操作的数据（例如OLTP应用程序），最好具有更多，更窄的表（例如具有较少字段的表）。 锁争用将减少，因为您仅将少量数据写入不同的表中。

因此，根据您描述的条件，我将拥有的表结构为：

Vehicle
  VehicleType
  Other common fields

CadillacVehicle
  Fields specific to a Caddy

SaturnVehicle
  Fields specific to a Saturn

为了进行报告，我将在不具有规范化结构的完全不同的服务器上拥有一个完全不同的数据库（例如，仅将CadillacVehicle和SaturnVehicle表与“车辆”表中的所有字段都复制到其中）。

使用正确的索引，即使OLTP数据库在您的SELECT语句中也可能是高性能的，而不管存在数千万行的事实。 但是，由于您提到存在大量处理器报告，所以这就是为什么我会有一个完全独立的报告数据库。

最后的评论。 关于业务规则...数据存储不在乎业务规则。 如果各模型之间的业务规则不同，则实际上不应将您纳入有关数据库模式的设计决策中（除了帮助指示哪些字段为可空值及其数据类型外）。

Answer 3

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

Answer 4

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

Answer 5

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

一种是OLTP（在线事务处理）系统，应该对其进行高度标准化，以使数据模型高度正确。 报表性能一定不是问题，您将根据具体情况使用索引/非规范化等方式处理非报表查询性能。 数据模型应尝试与概念模型非常紧密地匹配。

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

Answer 6

我想说第一种方法看起来更好。

您是否有第二种理由想要这样做？

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

第二种方法似乎很难维护。

除非有确凿的理由要采用第二种方法，否则我将采用第一种方法。

Answer 7

根据您对我们的描述，答案是两种。

换句话说，您没有给我们足够的信息来给出正确的答案。 请说明您希望对数据执行哪种查询。

[话虽如此，我认为答案将是第一个；-)当我成像时，即使它们是不同的模型，每种模型的数据也可能非常相似。

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

编辑：鉴于您已更新了编辑内容，我肯定会说第一个。 由于它们具有相同的数据，因此它们应该进入同一表。

Answer 8

定义“更好”时要考虑的另一件事-最终用户会直接查询此数据吗？ 高度标准化的数据对于最终用户来说很难使用。 当然，可以通过视图解决此问题，但是在完成设计时仍然需要考虑。

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

Answer 9

选择取决于所需的性能。 最好的数据库是规范化数据库。 但是规范化数据库中可能存在性能问题，那么您必须对其进行非规范化。 “首先归一化，为性能而去归一化”的原理很有效。

Answer 10

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

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

table_model
* type {cadillac, saturn, chevrolet}

Answer 11

@mson提出了一个问题“在SO上不能令人满意地回答问题时，您会怎么做？ ”，这直接引用了该问题的现有答案。

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

---

引用（普通）：

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

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

因此，我不认为起点是合理的。 我没有批评它。 这还不够引人注目，并且有一些答案，所以我让其他人尝试一下。

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

最终，这将取决于人们对数据的使用方式。 如果信息将朝着各个不同的方向飞散（不同品牌的数据结构不同；汽车模型级别的数据结构不同；针对不同经销商的结构不同-雪佛兰经销商与土星经销商和凯迪拉克的处理方式不同）经销商），则集成结构提供的收益有限。 如果一切都一样，那么集成结构将带来很多好处。

分离数据是否有法律理由（或利益）？ 不同品牌在多大程度上分开了法人实体，共享记录可能会构成负债？ 是否存在隐私问题，如果单独存储不同品牌的数据，将更容易控制对数据的访问？

如果没有对场景进行建模的更多细节，没有人可以给出可靠的一般答案-至少不超过已经给出（或没有给出）最高投票的答案。

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

---

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

从SO常见问题解答页面中：

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

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

• 详细而具体
• 清楚清楚地写
• 至少在某个地方有其他程序员感兴趣

...

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

避免提出主观，争论或需要扩展讨论的问题。 这是一个可以回答问题的地方！

国际海事组织，这个问题接近“ 需要进一步讨论 ”的限制。