hibernate - 当应用程序使用持久层或存储库时，DBA 是否有角色？

Question

我正在重新构建一对使用 Hibernate 的应用程序，第二种情况是 Hibernate 和 Java Content Repository(特别是 JackRabbit )的组合。

重新架构的一个关键问题是提高性能，所以我想知道为应用程序的设计和开发引入 DBA 是否有任何值(value)。

请注意，我并不是在质疑让 DBA 参与管理生产数据库的值(value)。但在过去的项目中，在设计和编码阶段有一个优秀的 DBA 参与，找出优化数据结构的方法，将代码放入存储过程等是必不可少的。

但考虑到数据库结构几乎完全由 Hibernate 和 JackRabbit 管理，优化它们的余地不大。当然，如果我们发现它们表现不佳，DBA 可能会发现问题，我们可以提交补丁来改进它们，但我不知道我们是否希望(或能够)在应用程序方面做很多事情——具体调。

对 DBA 在此类应用程序中的角色感到疑惑的另一个原因是，我们的大部分性能问题很可能在持久层之上，即不是数据库、 hibernate 或 JackRabbit 太慢，而是这样我们已经构建了我们的数据并推送它不是很好。解决这个问题将涉及数据建模，但实现媒介是 XML 文件和 Java 代码，而不是数据库表和 SQL。 DBA 通常对此类事情了解很多吗？

在设计和开发构建在持久层之上的应用程序时，让我无法完全排除对 DBA 的需求的原因是怀疑。我不太相信使用预先打包的解决方案可以完全消除对特定应用程序的数据库优化的需求。

我错过了关键点吗？熟练的 DBA 是否可以调整 hibernate 配置文件，以便为我的应用程序的特定用例提供极快的速度？在没有 DBA 手动调整 DB 本身、构建索引等的情况下，考虑运行高负载 Hibernate 应用程序是不是很疯狂？或者在开发环境中是否有专门优化基于 XML 的数据模型和抽象持久层的新生物？

Answer 1

有 DBA 和 DBA。一些 DBA 是管理员——备份、恢复、授权、撤销——一类人。保持灯亮。基础。

其他 DBA 是架构师/设计师。 “解决这个问题将涉及数据建模” 这就是 DBA 的第二层应该做的事情。

许多管理员 DBA 被推到架构师的角色——毕竟他们知道 SQL——但并不真正适合它。你知道你找错人了……

他们痴迷于表和列命名约定。

他们痴迷于 FK/PK 关系，而忽略了这样一个事实，即一旦您获取了行并将它们变成了对象，您就有了许多丰富、复杂的集合类可用于管理关系。

他们不能将表中的行与应用程序中的对象以及两者都实现的现实世界实体分开。这通常是一个阻碍。如果您有一个复杂的现实世界对象，它是由复杂的编程语言结构实现的，并且还映射到复杂的数据库结构，那么它可能会令人困惑。有些人退回到他们的舒适区并开始重复无意义的短语，例如“一切都只是一点点”或“最终，一切都是 FK，甚至对象引用”。

要求一切都是存储过程，“因为它更快”。如果他们不能提供证据，情况会更糟。

重点来了……

性能取决于两件事: 数据结构和算法 。通过选择正确的数据结构和算法来最大限度地减少资源使用(I/O、内存等)。

数据库非规范化是一种调整数据结构以匹配算法的方法。其他性能调优的概念大致相同:更改参数和选项以使数据结构更好地匹配应用程序算法。

这应该是双向的。您应该查看您的实体、您的需求，并计算出 数据结构和算法来做正确的事情。完成此操作后，您可以调整缓冲区的大小以及其他内容，以获得更好的性能。

从根本上说，极快的速度来自于考虑最内部最内部的循环:它们在循环什么？他们在寻找什么？如何用不循环或根本不循环的东西替换它们？

如果您的 DBA 可以参与算法和数据结构设计，那么它们就是一种 Assets ，请大量使用它们。

如果您的 DBA 不能参与，那么不要将您的设计限制在他们喜欢的范围内。