我有几个关于hibernate的问题。
许多问题中，有好几个人都说hibernate对于非常复杂的数据库不是一个好选择。如果我们有非常复杂的数据库，hibernate是不正确的选择。它更适合于绿色项目，但对于复杂的遗留数据库却不是那么好。
这是真的？ hibernate也会生成查询。每个项目经理都希望拥有优化的查询（hibernate所生成的优化查询比sql专家还要多！）。因此，对于大型项目，雇用sql专家不是问题。sql专家将优化查询（使用解释sql，使用联接…）
我的问题是，为什么一个庞大而昂贵的项目不关心sql优化？ （您会说您可以编写HQL，但是正如我在许多帖子中所看到的那样，它解释说HQL并不比sql强大，并且许多程序员会头疼和需要数小时的调整）（您喜欢自己的所有器官工作的理想状态是吗？）而且二级缓存对hibernate有很大帮助，因为hibernate知道会生成很多查询而不是复杂的联接。
我的问题是：真的只有一个系统（例如网站）修改了复杂的数据库吗？如果我们谈论的是企业系统，则可以通过几个进程访问数据库，它们共享不同的编程语言和平台。 因此，在这种情况下，二级缓存没有太大帮助。
hibernate适合什么样的项目？是否适用于没有人关心sql的后台项目？
当您的管理员说：请使用memcached进行缓存，并使用此优化查询而不是您的查询时，会发生什么？
如果使用的是oracle数据库，则orache具有最高级的sql语法。他们花了很多时间和金钱在非常强大的语法上。如果不使用此语法，它的作用是什么。
该软件仅编写一次（然后维护），并且使用了很长时间。如果我是一家订购软件的公司，我会说：我将使用该软件几年，并且我希望自己速度更快，如果您花1个月的时间使用hibernate编写软件，我将再支付一个月的使用时间例如，IBATIS知道它可以在多年内更好地工作 （当您购买汽车时，您对1kg-油/ km的汽车经济性感兴趣，而不是制造商生产汽车的时间和便捷程度！）。因此，作为软件使用者，我对您的生产率不感兴趣，而对软件的速度不感兴趣。当然价格也是相关的，但是如果我们谈论价格，则有更复杂的数学。
当我们真的无法预测系统的某些部分时，可以将其称为工程学吗？ （如果电气工程师无法预测电流，电气工程师真的可以成为工程师）
请分享您的意见。
问候
1）（…）这是真的吗？
不，不是的，Hibernate可以处理相当复杂的数据库，包括现有的数据库。但是，对于高度非规范化的数据库或奇异的架构，它可能无法很好地处理。这是不同的。
2）（…）我的问题是，为什么一个庞大而昂贵的项目不关心sql优化？
这是胡说八道，使用Hibernate并不意味着您不在乎优化。我已经在一个庞大而复杂的STP系统上工作（几亿欧元的预算），性能绝对是一个重要的问题，我们实际上引入了Hibernate来受益于诸如延迟加载，二级缓存（并加快开发）之类的事情。
这是使用像Hibernate这样的ORM时的交易（适当时）：
3）（…）因此，在这种情况下，二级缓存没有太大帮助。
好吧，您对以下事实是正确的：理想情况下，使用二级缓存意味着使用Hibernate API（尽管您仍然可以“手动”退出缓存，尽管我倾向于将其用于“大多数已读取”实体）。但是，更重要的是，根据我的经验，通过数据库在许多应用程序之间共享数据只会导致应用程序无法维护（更改单个位变得不可能，因为这可能会影响多个应用程序），因此应避免。使用EAI / ESB并通过它公开主系统的服务。这样，您可以重用业务逻辑，第二级缓存等。
4）（…）Hibernate适用于哪种项目？是否适用于没有人关心sql的后台项目？
Hibernate对于CRUD应用程序确实非常好，但不仅如此（参见上文），而且您的问题显示出我已经说过的一些无知。但是，它不适合任何项目：
5）（…）当您的管理员说：请使用memcached进行缓存，并使用此优化查询代替您的查询时，会发生什么？
我告诉他，memcached可能不是我们上下文中的最佳解决方案（不，我不想一直通过网络发送数据，而且我不在乎Facebook / LiveJournal / Twitter /无论使用什么，我们的应用可能有不同的需求），与Hibernate合作时还有其他更好的缓存实现，我请他与我讨论 问题 ，并讨论各种 解决方案 ，等等。我们作为一个团队工作，而不是互相反对。
综上所述，ORM解决方案并不总是合适的，但我认为您当前有偏见，我的经验与您的问题中表达的观点（怀疑？）不同。
