最近我遇到了这样一个模式模型
结构看起来完全一样，我只是用实体名重命名，比如table（*），从表c开始，所有的表都有将近200列，从c到l
发布这篇文章的原因是，我以前从来没有遇到过这样的结构，如果有人已经经历过这样或工作类似或更复杂，请分享你的想法，
有这样的结构是好是坏，为什么？
假设我们需要api来为这样的表结构保存数据，那么如何设计api呢
我们将如何跨所有这些表管理事务
在服务代码中，很少有需要从这些表中获取数据并传输到外部系统的情况。这里的关键是，外部系统正在接受扁平结构中的请求，而不是我们上面提到的层次结构中的请求。如果需要将这些数据传输到外部系统，如何管理封送和取消封送
最后但并非最不重要的是，像这样管理数据的api每天至少可以消耗2k。
你是怎么想的，我不知道我们为什么需要它，它需要一个详细的讨论，我们需要打破的东西。
如果我考虑spring数据jpa，hibernate。我需要考虑的是什么，
更重要的是，所有这些表的行值都将基于ownerid/tenantid进行限制，因此所有表的数据都需要一致。
1条答案
按热度按时间oipij1gg1#
我不能评论结构的一般方面，因为这是相当领域特定的，人们需要知道为什么选择这个结构，以便能够说它是好是坏。不管怎样，你可能无论如何都无法改变这一点，那么为什么还要费心问它是好是坏呢？
尽管如此，对于这样一个模型，您应该考虑以下几个方面：
在更新数据时，只更新真正更改的列非常重要，这样可以避免索引损坏，并允许数据库在页面中使用备用存储。在hibernate这样的模型中使用hibernate通常会更新所有“可更新”列，而不仅仅是脏列，这是一个性能问题。但是有一个选项可以进行动态更新。在没有动态更新的情况下，每次更新可能会产生更多的ios，从而使锁保持更长的时间，这会影响整体的可伸缩性。
在读取数据时，默认情况下不要使用连接获取非常重要，因为这可能会导致结果集大小爆炸。