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

我正在重新构建一对在一种情况下使用Hibernate的应用程序,以及第二种情况下Hibernate和Java 内容存储库(特别是JackRabbit)的组合.

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

请注意,我并没有质疑让DBA参与管理生产数据库的价值.但是在过去的项目中,必须让一个好的DBA参与设计和编码阶段,找出优化数据结构的方法,将代码放入存储过程等等.

但鉴于数据库结构几乎完全由Hibernate和JackRabbit管理,因此优化它们的余地不大.当然,如果我们发现它们表现不佳,DBA可能会发现问题并且我们可以提交补丁来改进它们,但我不知道我们希望(或能够)在应用方式上做很多事情 - 具体调整.

想知道DBA在这种类型的应用程序中的作用的另一个原因是我们的大部分性能问题很可能在持久层之上,即数据库,休眠或JackRabbit并不是太慢,就是这样的我们已经构建了我们的数据并推动它并不是很好.修复此问题将涉及数据建模,但实现介质是XML文件和Java代码,而不是数据库表和SQL.DBA通常对此类事物了解多少？

在建立在持久层之上的应用程序的设计和开发中,让我完全不再需要DBA的事情令人怀疑.我不太相信使用预先打包的解决方案可以完全消除对特定应用程序进行数据库优化的需求.

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

有DBA,还有DBA.一些DBA是管理员 - 备份,恢复,授权,撤销 - 类型的人.保持灯亮.基础性.

其他DBA是建筑师/设计师."修复这将涉及数据建模"这就是DBA的第二层应该做的事情.

许多管理员DBA都是建筑师的角色 - 毕竟他们知道SQL - 但并不适合它.你知道你在......时遇到了错误的人

他们着迷于表和列命名约定.

他们痴迷于FK/PK关系,忽略了这样一个事实:一旦你获取了行并将它们变成了对象,你就可以使用许多丰富,复杂的集合类来管理关系.

它们不能将表中的行与应用程序中的对象以及两者都是实现的实际实体分开.这通常可以成为一种表现.如果您有一个复杂的现实世界对象,该对象由复杂的编程语言结构实现,并且还映射到复杂的数据库结构,则会让人感到困惑.有些人退回到他们的舒适区,并开始重复无意义的短语,如"这只是一点点"或"最终,一切都是FK,甚至是对象参考".

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

这是重点......

性能取决于两件事:数据结构和算法.通过选择正确的数据结构和算法来最小化资源使用(I/O,内存等).

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

这应该是双向的.你应该看看你的实体,您的需求,制定出双方是做正确的事的数据结构和算法.一旦你完成了这个,你就可以调整缓冲区的大小,而不是为了获得更好的性能.

从根本上说,炽热的速度来自于考虑内部最内部的循环:它们循环的是什么？他们在寻找什么？如何将它们替换为不循环或根本不循环的东西？

如果您的DBA可以参与算法和数据结构设计,那么它们就是一种资产,大量使用它们.

如果您的DBA无法参与,那么请不要将您的设计限制在他们熟悉的范围内.