泛型模型是反模式吗？答案

【问题标题】：Is a generic model an antipattern?泛型模型是反模式吗？
【发布时间】：2010-03-04 07:20:44
【问题描述】：

现在我有一些我以前没有见过的东西：数据库真的很通用。例如：我们有一个通用类型而不是具体类型：设备，它与自定义属性表相关。

不幸的是，其实体上的模型代表了这些表，因此模型根本不谈论业务。

最后编程很混乱：没有人设计或定义应该在通用表中的自定义属性，因此很难知道在哪里放置什么。而且你需要很多代码来检索一个属性。

您认为具有通用模型的通用数据库是某种反模式吗？有高手吗？

【问题讨论】：

【解决方案1】：

这让我想起了Inner Platform Effect。基本上，数据库被简化为第二个数据库系统，您的具体类型在其中实现。

【讨论】：

【解决方案2】：

我过去使用过一个非常通用的数据库。这是管理具有非常频繁变化的需求和突然出现的意外互连的庞大系统的一种明智的方式。

虽然执行的是 3 种表：存储某些数据类型的主要“通用”表、链接表（表来源、链接来源、表到、链接到、记录类型）和表的表，定义存储什么类型的数据，以及如何存储。当然，这会产生一些开销，但这被引擎定制所抵消，这些定制真正加快了通用请求并保持了复杂请求的合理性（并且很少见）。

所以，虽然我同意在一般情况下这是一种反模式，但在某些情况下这是正确的做法。一个特定的场景是系统是一个通用平台，非技术人员通过将通用块组合在一起来创建新服务。块连接到“数据类型”表，但这些表将如何使用（以及块将填充什么）留给用户。

【讨论】：

但是它上面的模型管理了复杂性，还是您的每个表都有一个实体？
运行它的平台根据每个块中指定的默认值执行查询（可能有几个不同的块使用一个表，通常在完全不同的上下文中。一些块一次使用两个或多个表），使用这些块的配置中的细节。平台执行执行，但所有业务逻辑都附加到块上，一些是永久的（选择什么...），一些编码为每个实例的配置（...WHERE什么）。
在反思中：当使用它而不是你做作业来获取系统规格时，它是一种反模式。如果你做了功课并且规格是“规格会不断变化，请处理它”，这是一个有效的模式。

【解决方案3】：

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

【讨论】：