java - Hibernate 是否必须驱动数据库设计？

Question

我昨天一整天都在阅读关于 Hibernate 的各种文章/教程，虽然我被它的强大所震撼，但我对它有一个主要的担忧。

似乎标准做法是允许 Hibernate 为您设计/生成您的 DB 模式，这是一个令我窒息的新概念和可怕概念。从我阅读的教程中，您只需将一个新实体添加到您的 hibernate.cfg.xml 配置文件，使用 @Entity 注释您想要的任何 POJO，然后瞧 - Hibernate 创建给你的表。虽然这很酷，但它让我想知道一些场景:

• 如果您已经有一个 DB 模式，而 Hibernate 想要为您生成的模式不符合该模式怎么办？如果您有一个疯狂的 DBA 拒绝在预定义(非 Hibernate)模式上让步怎么办？
• 如果您有包含数万条记录的引用表(就像世界上所有城市一样)怎么办？您是否必须实例化并save() 数以万计的独特 POJO，或者是否有一种方法可以配置 Hibernate，使其能够尊重而不是覆盖您的表中已经存在的数据？
• 如果您想对架构/表进行性能调整怎么办？这包括索引、规范化以及超出 Hibernate 自动创建的内容？
• 如果您想向表中添加约束或触发器怎么办？索引？

我想这的根源如下:

看起来 Hibernate 在您的数据库上创建并强制执行特定的模式/配置。我想知道这个议程将如何与我们的平台标准、我们的 DBA 理念以及我们对与 Hibernate 交互的表进行调优/微调的能力发生冲突。

提前致谢。

Answer 1

我认为您将过多的功能归功于 Hibernate。

Hibernate 确实有一个可能影响数据库实现的习惯用法。

Hibernate 不会为您生成模式，除非您要求它这样做。可以从现有模式开始并使用 Hibernate 将其映射到 Java 对象。但如果架构与 Hibernate 要求冲突，则可能无法实现或无法实现最佳。

如果 DBA 不让步——他们不应该让步——或者 Hibernate 不能适应你，那么你就有了答案:你不能使用 Hibernate。

您的 DBA 可能会同意，但您的应用程序可能会发现 Hibernate 为您生成的动态 SQL 不是您想要的。

幸运的是，这不是镇上唯一的游戏。

我不认为实现必须是全部或全部。如果使用简单的 JDBC 访问引用数据，有什么危害？

数据库设计注意事项应该独立于 Hibernate。约束、触发器、规范化和索引应该由业务需求驱动，而不是您的中间件选择。

如果您没有实体对象模型，或者架构无法容纳它，那么您应该重新考虑 Hibernate。有直接的 JDBC、存储过程、Spring JDBC 和 iBatis 作为替代品。