问题描述
最近我遇到了这样的模式模型
结构看起来完全一样，我只是使用表（*）之类的实体名称进行了重命名
从表C开始，从C到L，所有表都有近200列
发布此信息的原因是，我以前从未遇到过这样的结构，如果有人已经经历过这样的工作，或者工作过类似或更复杂的工作，请分享您的想法，
-
具有这样的结构是好是坏，为什么？
-
假设我们需要API来保存像这样的表结构的数据， 如何设计API
-
我们将如何在所有这些表中管理事务处理
-
在服务代码中，在少数情况下，我们可能需要从这些表中获取数据并传输到外部系统。 此处捕获的是，外部系统正在不采用如上所述的层次结构中的扁平化结构中接受请求。如果需要将这些数据传输到外部系统，我们如何管理封送和取消封送
-
最后但并非最不重要的一点是，每天将要消耗至少2K的API来管理此类数据。
您对此有何想法，我不知道我们为什么需要它，它需要进行详细的讨论并且我们需要分解。
如果我考虑使用Spring Data JPA，请使用Hibernate。我需要考虑的是什么，
更重要的是，所有这些表的行值都将根据ownerId / tenantId进行限制，因此所有表中的数据都必须保持一致。
解决方法
我无法评论该结构的一般方面，因为它是特定于领域的，因此需要知道为什么选择此结构才能说出它是否好。无论哪种方式，您都可能无法更改，那么为什么还要问它是否好呢？
已经说过，使用这种模型，您应该考虑几个方面：
- 更新数据时，仅更新真正更改的列非常重要，这样可以避免索引浪费并允许DB在页面中使用备用存储。当将Hibernate与此类模型一起使用时，通常会出现性能问题，因为Hibernate通常会更新所有“可更新”列，而不仅仅是脏列。但是，有一个选项可以进行动态更新。如果没有动态更新，则每次更新可能会产生更多的IO，从而使锁定时间更长，从而影响整体可伸缩性。
- 读取数据时，非常重要的一点是，默认情况下不使用联接获取，因为这可能导致结果集大小爆炸。