首先，我不是DBA，但我确实在DBA不时调整/更改生产数据库的环境中工作，不会导致需要重建/重新部署应用程序。通常，这些更改包括重写索引，更改过程，有时以较小的方式更改表结构（通常通过过程从应用程序中抽象）。
显然，团队应该在使用NHProf，SQL Profiler和负载测试之类的东西进入生产之前，努力解决NHibernate的性能问题。话虽如此，是否有某些策略可用于在代码构建完成后在生产中运行时进行一些调整？使用存储过程100％的时间似乎可以为DBA提供最大的灵活性，但显然这会破坏NHibernate的效率。从我读过的内容来看，可更新视图（在SQL Server中）对NHibernate来说效果不是很好（这可能或者可能不是真的）。
我已经阅读了很多关于NHibernate的内容并多年来对它进行了实验，但我从未在生产环境中将其付诸实践。我还没有遇到一套“最佳实践”，以便在部署后进行最大程度的调整。
作为NHibernate用户，您和您的团队如何处理问题（如果它们出现在生产中）？我的生产环境由ASP.NET应用程序和SQL服务器组成，但我不认为答案需要限制在该平台上。
答案 0 :(得分：1)
我还没有进入部署阶段，但是在我目前的项目中，我已经遇到了这个问题，我的解决方案目前是用存储过程替换我的查询。只要从数据库返回的数据的形状保持不变，这不是什么大问题。是的，你确实失去了在开发过程中所享受的一些敏捷性，但我不确定它是否与最初的声音一样糟糕。当你第一次做出改变的时候，你会有一个代码推送，然后从那一点开始，它就是proc更改。
答案 1 :(得分：1)
我处于类似的位置，为了让我们的DBA满意，我做了以下事情：
通过这种方法，DBA可以理论上通过修改这些文件来调整查询。这与存储过程非常相似。
在练习中，您可以自行决定是否真的让DBA访问这些文件（如果您抓住我的漂移......）
恕我直言，DBA应该只使用DBMS的分析工具，并将她的发现报告给开发人员（如“这个查询运行20次/秒并进行10次连接。这是非常必要的吗？可以缓存吗？”你真的需要所有这些连接吗？我们可以对它进行反规范吗？“等等。答案 2 :(得分：0)
您可以使用NHProf之类的探查器查看已执行的SQL查询，以便将其显示给DBA。此工具还可以检测到一些问题，如n + 1选择。