database - 系统设计: whether to normalize the departments or not

Question

我在一个项目中与两位顾问合作。问题是我们已经到了一个地步，他们都无法达成协议(protocol)，而且每个人都提供了不同的方法。

问题是我们有一家商店有四个部门，我们想找到在同一个数据库中与所有部门合作的最佳方法。

每个部门销售不同的产品:汽车、船只、摩托艇和摩托车。

当每个部门插入或更新数据时，会有一些触发器被触发，因此不同的工作流程将开始，当添加新车时，需要检查某些要求以及汽车的详细信息与船完全不同。此外，关于数据，没有太多共同的字段，我想说到目前为止只有品牌、颜色、型号和年份，其他所有内容都是针对每个部门的，因为不同的产品以及它们如何使用它们。

一位顾问说:

• 为所有部门创建一个表，并使用一列来标识该行属于哪个部门，这样您将只有一个触发器，然后在触发器内您将调用每个部门所需的函数/方法记录类型。

• 原因:您只有一张表(包含 200 多个字段)和一个触发器，更易于维护。此外，如果您需要报告，您只需要查询一个表并根据记录类型进行过滤。如果您需要报告所有项目，则不需要进行多重联接。

顾问二说:

• 为每个部门创建一个表，并为每个表创建一个触发器。

• 原因:您将拥有更小的表(每个表大约 50 个字段)并且更灵活，并且您将它们全部分开。如果您想要报告，您需要加入表格，因为您想要包含来自不同地方的数据。

我看到了将所有内容都集中在一个地方的优势，但如果我想扩展或更改任何内容，我感觉我将随着数据的增长而创建一个野兽表。

另一方面，保持分离看起来更吸引人，但需要为每个不同的表设置所有内容。

您认为最好的方法是什么？

Answer 1

您可能应该听听二号顾问的意见。

事实是，所有设计都是权衡取舍。您需要评估每种方法的优缺点，并且需要考虑每种设计所带来的风险。

• 当您的设计发展壮大时会发生什么？ (第 5 部门，每种产品类型的更多详细信息，...)
• 当系统扩展到更高的交易量时会发生什么？
• 当您的业务规则发生变化时会发生什么？

我已经这样做了很长时间，并且我看到一些钟摆在谈到数据库和软件最佳实践方面的“时尚”时来回摆动。

我想说现在流行的观点是关注点分离天生就是好的。这意味着您应该将每个部门的程序逻辑(触发代码)分开。这是有道理的，因为您的逻辑会因一种产品类型而异，因为它们大多具有不同的列。

第二点也很重要，因为您在交易系统基础上的利益应始终从第三范式开始(或更高，如有必要)。有时没有它你也可以逃脱，但是四种不同类型的对象具有 40 种或更多不同的属性，每种对象听起来不像是将所有内容都塞进一张表的好选择。例如，您如何跟踪哪些列属于哪种类型的产品？每种产品类型都有一个单独的表格，使您的支持程序员易于理解这一点，保持简洁明了 - 重要的是 - 很容易理解。

与一位顾问所说的相反，如果一个触发器是一大碗意大利面条，或者甚至是四个整洁、编写良好的子例程与 switch 类型语句。

现在，程序员喜欢简短的、原子的、单一用途的函数(在你的例子中是触发器)。

如果有足够多的通用数据和通用业务逻辑，以至于重复四次看起来很尴尬，那么也许您有一个很好的父类(super class)型/子类型设计候选者。