在传统世界中需要Hibernate

我有几个关于hibernate的问题。

在stackoverflow中的许多问题中，有几个人说hibernate对于非常复杂的数据库来说不是一个好选择。 如果我们有非常复杂的数据库，那么hibernate不是正确的选择。 它更适合绿色领域项目，但对复杂的遗留数据库来说并不是那么好。

1. 这是真的？
   hibernate还会生成查询。 每个项目经理都希望有优化的查询（hibernate不能生成比sql专家更优化的查询！）。 因此对于大型项目来说，聘请sql专家不是问题。 sql专家将优化查询（使用explain sql，使用连接…）

2. 我的问题是如何一个庞大而昂贵的项目不关心sql优化？
   （你会说你可以编写HQL，但正如我在很多post中看到的那样，解释说HQL并不比sql强大，而且很多程序员都会头疼并且需要几个小时的调整）（你喜欢你的所有器官）理想情况下你的身体不工作吗？）另外，二级缓存有助于hibernate，因为hibernate知道生成大量查询而不是复杂的连接。

3. 我的问题是：真的是一个复杂的数据库，只能由一个系统修改（例如网站）吗？ 如果我们谈论企业系统，可以通过多个进程访问数据库，共享不同的编程语言和平台。
   所以在这种情况下，二级缓存并没有多大帮助。

4. 什么样的项目适合hibernate？ 它适用于没有人关心sql的后台项目吗？

5. 当您的管理员说：请使用memcached进行缓存时，请使用此优化查询而不是您的查询？

如果您使用的是oracle数据库，那么orache拥有最先进的sql语法。 他们花了很多时间和金钱在非常强大的语法上。 如果不使用它，该语法是什么？

该软件只编写一次（然后维护）并使用很长时间。 如果我是一家订购软件的公司，我会说：我将使用该软件几年，我喜欢快速，如果你花1个月的时间用hibernate编写软件，我将再支付一个月的软件使用例如IBATIS知道它可以多年使用更好
（当你购买汽车时，你对汽车经济1公斤油/公里感兴趣，而不是制造商生产汽车的简单和简单！）。 因此，作为软件消费者，我对您的工作效率并不感兴趣，只是软件的速度有多快。 当然价格也是相关的，但如果我们谈论价格，那么就有更复杂的数学。

当我们真的无法预测系统的某些部分时，我们可以称之为工程吗？
（如果无法预测电流，电气工程师真的可以成为工程师）

请分享您的意见。

问候

Answer 1

1）（…）这是真的吗？

不，不是，Hibernate可以处理非常复杂的数据库，包括现有数据库。 但是，它可能无法很好地处理严重非规范化的数据库或异国情调的架构。 这是不同的。

2）（…）我的问题是如何一个巨大而昂贵的项目不关心sql优化？

这是无意义的，使用Hibernate并不意味着你不关心优化。 我已经开发了一个庞大而复杂的STP系统（几亿美元的预算），性能绝对是一个重要的问题，我们实际上引入了Hibernate，从延迟加载，二级缓存（和加速开发）等方面受益。

这是使用像Hibernate这样的ORM时的交易（适用时）：

• 使用ORM比使用ORM更快（或者使用它们没有任何意义）。
• 绝大多数生成的查询都会正常运行（事实上，Hibernate生成的SQL比普通开发人员更好 ）。
• 您可以（并且必须）在一定程度上调整查询和hibernate。
• 即使您花了一些时间进行性能优化（包括回退到本机SQL以查找真正有问题的查询），您仍然可以更快地完成。

3）（…）所以在这种情况下，二级缓存没有多大帮助。

好吧，你是对的，事实上使用二级缓存理想地意味着使用Hibernate API（尽管你仍然可以“手动”逐出缓存，尽管我倾向于将它用于“大多数读取”实体）。 但是，更重要的是，根据我通过数据库在许多应用程序之间共享数据的经验只会导致无法维护的应用程序（改变单个位变得不可能，因为它可能影响多个应用程序）并且应该避免。 使用EAI / ESB并通过它公开主系统的服务。 这样，您可以重用业务逻辑，二级缓存等。

4）（…）hibernate适合哪种项目？ 它适用于没有人关心sql的后台项目吗？

Hibernate确实非常适合CRUD应用程序，但不仅如此（见上文），你的问题显示了一些无知，正如我已经说过的那样。 但是，它不适合任何项目：

• 我可能不会将它用于数据仓库或大型报表应用程序。
• 我可能不会将它用于严重非规范化或异国情调的遗留数据库（在这种情况下像mybatis这样的数据映射器可能是更好的选择）。
• 我可能不会将它用于使用存储过程的现有系统。
• 我不会将它与非RDBMS数据存储区一起使用:)

5）（…）当您的管理员说：请使用memcached进行缓存时，请使用此优化查询而不是您的？

我告诉他memcached可能不是我们上下文中的最佳解决方案（不，我不想总是通过网络发送我的数据，我不关心Facebook / LiveJournal / Twitter /无论使用它，我们的应用程序可能有不同的需求），在使用Hibernate时还有其他更好的缓存实现，我请他与我讨论问题 ，我们讨论各种解决方案等。我们团队合作，而不是互相攻击。

总而言之，ORM解决方案并不总是合适，但我认为您目前有偏见，我的经验与您的问题中表达的观点（误解？）不同。

也可以看看

• 何时不在Java中使用O / R映射

Answer 2

这对绿色领域项目有利，但对传统项目也有好处。 您可能需要执行一些映射技巧，但它提供了相当灵活的映射。

由于您可以使用本机查询，并且由于您可以将其与您喜欢的缓存解决方案集成，因此您不需要因为使用Hibernate而遇到任何性能问题。 当您的数据库管理员说您应该使用memcached时，您可以使用此memcached / Hibernate集成 。 您可以使用自己喜欢的缓存编写缓存实现并插入Hibernate 。 当她说你应该使用这个优化的查询时，你说“太棒了！Hibernate有一个原生的SQL工具 ，可以让我使用那个查询”。 您可以使用本机Oracle语法，您可以使用您选择的任何RDBMS的本机语法。

多应用程序环境对Hibernate提出了与任何解决方案相同的挑战。 如果您希望应用程序运行良好，您将使用相当于二级缓存的内容。 Hibernate恰好提供与缓存集成的ORM。 它没有解决跨多个应用程序协调缓存的问题，但即使您不使用Hibernate，也必须解决该问题。

Answer 3

你的问题可能太宽泛了。 我可以告诉你我的经历。

我参与了一个采用.NET版本（NHibernate）的项目。 从单个表加载单行的简单实现几乎比原始ADO查询慢两个数量级。 经过多次优化后，我相信它们只能降低一个数量级。

在java中，启动时间可能不是一个因素。 Web服务器在服务器启动时加载java和hibernate，而不是在用户等待桌面应用程序启动时加载。

我个人真的不喜欢它。 它隐藏了有效管理数据所需的实施细节。 我发现没有真正的世界应用程序可以通过隐藏数据库详细信息的数据层的vanilla实现来实现可接受的性能。 但这可能是我自己的酸葡萄，因为我被迫使用它，并指责无法在猪上涂上足够的口红。

Answer 4

1. 无论数据库有多复杂。 最重要的问题是应用程序的复杂域模型。

2. 查询select * from anytable where anycol = @anyvalue优化？ 我不知道。 没有人。 因为只有一个真正的优化标准 – 这就是这种查询的性能。 使用hibernate或其他ORM可以节省大量时间，然后利用这段时间查找实际上很慢的查询。 据我所知，Hibernate有一些方法可以使用优化查询。

3. 第三，你的问题很好。 但是，对于每次无处不在的脏数据都没有问题，没有人能回答这个问题。 严格说，直到锁定，从数据库读取的任何数据都是脏的，无论它是如何读取的以及存储的位置。 数据阻塞对性能不利，所以通常你应该在实际数据和性能之间找到妥协。

没有银弹。 ORM有很多优点，但只有一个不合适的情况：动态结果集取决于参数（当不同参数返回不同列集的数据时）。 因为对象结构在编译时是静态的（在静态类型语言中），ORM在这种情况下无法帮助。

其他所有案件都可以解决。 可以关闭实体服务（更改跟踪等），可以禁用二级缓存，并且可以使用优化查询而不是生成。 我不知道如何在Hibernate中做所有的事情，但我确信它是可能的。

ORM具有很大的优势，它将所有数据访问逻辑集中在可管理的forms中，并将其放在特定的位置。 此外，它支持在您自己的数据访问库中实现并不容易和直接实现的一些事情，如事务管理（包括嵌套事务等），标识映射（一行 – 一个对象），复杂层次结构持久化（如果您使用对象和对象层次结构），乐观锁定等，ORM可以极大地帮助您。