通用模型是反模式吗？
现在我有了以前从未见过的东西：数据库非常通用。例如：我们有一个通用类型：设备，而不是具体类型，它与自定义属性表相关。
不幸的是，其实体上的模型代表了这些表，因此该模型根本不讨论业务。
最后，编程非常混乱：没有人设计或定义应该在通用表中的自定义属性，因此很难知道在哪里放置什么。仅检索一个属性就需要大量代码。
您认为具有通用模型的通用数据库是某种反模式吗？有专业人士吗？
Now I have something that I have not seen it before: the database is really generic. For example: instead of a concrete type we have a generic one: device, and it relates to a custom properties table.
Unfortunatelly, the model over its entities represents those tables, so the model does not talk about the business at all.
At the end programming is quite confusing: noone has designed or defined that custom properties that should be in the generic table, so is difficult to know where to put what. And you need lot of code for just retrieve one attribute.
Do you think generic database with generic model is somekind of antipattern? Any pro?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这让我想起了内部平台效应。基本上，数据库被简化为第二个数据库系统，您的具体类型将在其中实现。
This reminds me of the Inner Platform Effect. Basically the database is reduced to a second database system in which your concrete types are implemented in.
我过去使用过一个非常通用的数据库。这是管理一个庞大系统的明智方法，该系统具有频繁变化的需求和突然出现的意外互连。
但执行的是 3 种表：主要的“通用”表，存储某些数据类型、链接表（表来源、链接来源、表至、链接至、记录类型）和表的表，定义什么类型数据的存储方式以及存储方式。
当然，这会产生一些开销，但这被引擎定制所抵消，引擎定制确实加快了通用请求的速度，并使复杂的请求保持合理（并且很少见）。
因此，虽然我同意在一般情况下这是一种反模式，但在某些情况下这是正确的做法。一种特定的场景是，系统是一个通用平台，非技术人员通过将通用块组合在一起来创建新服务。块连接到“数据类型”表，但如何使用这些表（以及块将填充什么）则留给用户。
I worked with a pretty much generic database in the past. It was a sensible way of managing a huge system with very frequently changing requirements and unexpected interconnections popping up.
The execution though was 3 kinds of tables: the main "generic" ones which stored certain data types, a table of links (table from, link from, table to, link to, record type) and a table of tables, defining what types of data are stored, and how.
Of course this created some overhead, but this was offset by engine customizations that really sped generic requests up and kept complex ones reasonable (and rare).
So, while I agree in general situation this is an antipattern, there are scenarios when this is the right thing to do. One specific scenario is when the system is a generic platform where the non-tech people create new services by combining generic blocks together. Blocks are connected to "data type" tables, but how these tables will be used (and what will the blocks be filled with) is left to the users.
除非它适用于某些通用领域，否则我会说它听起来确实像反模式。将其与映射到关系模型的通常对象/关系/对象进行比较，其中大多数表代表一些真实的域实体。这更加直观，更易于理解和维护，并且不需要所有开销（编码和执行）。
Unless it is for some generic domain, I would say it does sound like an antipattern. Compare that to the usual object/relational/object mapped to relational model, where most tables represent some real domain entities. That's much more intuitive, simpler to understand and maintain, and does not require all the overhead (in coding and execution).