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

昨天一整天我都在阅读关于Hibernate的各种文章/教程，尽管我被它的强大功能所震惊，但我对它有一个主要的担忧

似乎标准的做法是允许Hibernate为您设计/生成DB模式，这是一个新的可怕的概念，让我窒息。从我阅读的教程中，您只需将一个新实体添加到

hibernate.cfg.xml

config文件中，用

@entity

注释您想要的任何POJO，瞧，hibernate就会为您创建表。虽然这很酷，但它让我想知道一些场景：

• 如果您已经有了一个DB模式，而Hibernate想要为您生成的模式不符合该模式，该怎么办？如果您有一个疯狂的DBA拒绝在预定义（非休眠）模式上移动，该怎么办
• 如果你有参考表，里面有成千上万条记录（就像世界上所有的城市一样），会怎么样？您是否需要实例化并

  save（）

  数以万计的唯一POJO，或者是否有办法配置Hibernate，使其能够支持并且不会覆盖表中已有的数据
• 如果要对架构/表执行性能调优，该怎么办？这包括索引、规范化，以及Hibernate自动创建的内容之外的内容
• 如果要向表中添加约束或触发器，该怎么办？索引

我想其根源如下：

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

提前感谢。

否。您可以使用从现有数据库生成实体

使用Hibernate有两种方法。如果您有优秀的DBA或数据库设计器，那么最好先设计数据库，然后将其映射到hibernate。 另一方面，如果您没有DBA和优秀的开发人员，那么让Hibernate为您生成数据库。

Hibernate背后的概念是映射数据库和对象。因此它被称为ORM（对象关系映射）工具。

---

请阅读对象关系阻抗。

我认为您将太多的功能归因于Hibernate

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

Hibernate不会为您生成模式，除非您要求它这样做。可以从现有模式开始，使用Hibernate将其映射到Java对象。但是，如果模式与Hibernate需求冲突，那么它可能是不可能的或最优的

如果DBA不让步——他们不应该这样做——或者Hibernate不能容纳您，那么您的答案是：您不能使用Hibernate

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

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

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

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

---

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

Hibernate提供了一种默认的将对象映射到表的方法——就像一些工具/库一样，为了简单起见，它支持约定而不是配置

但是，如果希望以不同的方式将实体映射到数据库表，可以显式地告诉Hibernate如何映射这些实体（从更改表名等简单属性，到重新定义相关实体之间的外键关系以及如何持久化）

如果正确地执行此操作，则不需要实例化和保存现有数据，因为这将是毫无意义的—数据库已经以Hibernate完全理解的形式包含了有关实体的信息。（想想看——加载然后立即保存一个实体应该始终是禁止操作的，因此可以完全跳过。）

---

所以对你的问题的简短回答是“不”。如果不喜欢设计表，可以让Hibernate采用合理的默认值。但是，如果您确实想明确地设计模式，您可以这样做，然后将确切的模式描述给Hibernate。

这是quick'n dirty原型或简单教程的首选方式，但它远不是任何生产应用程序的首选方式。我更喜欢独立设计数据库，使用脚本生成模式、表、视图、索引等，并将模式映射到实体

只要映射在数据库中找到表和列，一切都正常

一旦数据库中有数据并且模式必须更改，就必须编写迁移脚本。你不能放弃一切，从头开始。本教程是为从Hibernate开始的开发人员编写的，他们必须尽快发现Hibernate，而不必处理复杂的SQL脚本。

• 如果您已经有了一个数据库模式

我不知道你从哪里得到这样的印象。Hibernate可以使用现有的模式。它相当灵活

• 如果你有参考表

将关系设置为惰性，它将不会自动加载。仅保存已更改的对象

• 如果要执行性能调整，该怎么办

只是不要使用生成的模式。这只是一个起点。您可以根据需要进行自定义

• 如果要向表中添加约束或触发器，该怎么办？我