通用模型是反模式吗？

Question

现在我看到了一些之前没有见过的东西：数据库非常通用。例如：我们有一个通用类型而不是具体类型：设备，并且它与自定义属性表相关联。

不幸的是，模型代表这些表中的实体，因此模型根本不涉及业务。

最终编程非常混乱：没有人设计或定义应该在通用表中的自定义属性，所以很难知道把什么放在哪里。并且你需要大量代码才能检索一个属性。

您认为具有通用模型的通用数据库是某种反模式吗？有任何优点吗？

- Pablo Castilla

Answer 1

这让我想起了内部平台效应。基本上，数据库被简化为第二个数据库系统，在其中实现了您的具体类型。

- Ozan

Answer 2

过去我曾使用一种通用的数据库。这是管理一个庞大系统的明智方式，因为这个系统具有非常频繁变化的需求和意外出现的相互关联性。

执行过程涉及3种类型的表：主要的“通用”表存储特定的数据类型，链接表（源自哪个表、源自哪个链接、连接到哪个表、连接到哪个链接、记录类型）以及定义存储数据类型和方式的表格表。 当然，这会产生一些开销，但是引擎定制可以真正加快通用请求的速度，并使复杂请求保持合理（并且不常见）。

因此，虽然我同意在一般情况下这是反模式，但在某些情况下，这却是正确的做法。其中一个具体情境是，当系统是一个通用平台时，非技术人员通过组合通用块来创建新的服务。块与“数据类型”表相连，但如何使用这些表（以及块将填充什么内容）则留给用户自行决定。

- SF.

---

但是它上面的模型管理了复杂性，还是你针对每个表都有一个实体？ - Pablo Castilla

运行该平台时，它按照每个块中指定的默认值执行查询（可能有多个不同的块使用一个表，在完全不同的上下文中）。使用这些块的配置中的特定内容进行执行。平台执行了操作，但所有业务逻辑都附加到块上，一些是永久性的（SELECT what...），一些是按实例配置编码的（...WHERE what）。 - SF.

在反射中：如果你没有获取系统规格的功课，就使用它是一种反模式。如果你已经做好了功课，并且规格是“规格会经常变化，请处理它”，那么这是一种有效的模式。 - SF.

Answer 3

除非是针对某些通用领域，否则我会说这听起来像是反模式。与通常的对象/关系/对象映射到关系模型相比，大多数表代表一些真实的领域实体。这更直观、更简单易懂、更易于维护，而且不需要所有的开销（在编码和执行方面）。

- Konrad Garus