Hibernate :真实世界中的模式导出？

Question

我很好奇在我的下一个项目中完全使用模式导出。我认为这是真正处理对象而不是底层数据库的一种非常有用的方法。只需创建并注释模型，然后导出它。

但是，从先创建表然后创建模型对象的习惯出发，我对完全使用模式导出有疑问。这主要是因为我真的深入到冬眠中去了。但是，我仍然很好奇，在使用模式导出时，这个区域列表是否会是一个问题。请分享你的经历。

table

• Surrogate /复合主键support

• Re-exporting之间的

1. 关系将重新创建所有的数据库，当我只想从许多模型中导出一些模型时？

谢谢

Answer 1

就我个人而言，我不喜欢导出DDL，原因如下。

1. 数据库可能是应用程序中最关键的基础设施之一，信任DDL生成的hibernate意味着您必须检查hibernate生成的所有DDL，以确保一切正常，检查过程就像编写DDL一样耗时。当发布一个新版本的应用程序时，您可能需要使用alter语句，并升级到- version x.sql脚本，以修改现有数据库以使新数据库与新版本一起工作。此时，自动DDL生成不会对您有所帮助，因为带注释的hibernate类只会生成CREATE语句，而不会更改DDL语句。
2. Hibernate/JPA注释分为逻辑和物理两类。逻辑注释将类似于@实体，而物理注释将类似于@Table、@Columns .等等，在物理注释上定义的属性不足以精确控制为SQL生成的数据库类型。例如，假设您有一个包含日期的列，并且在其上使用@ column，@Temporal注释，通常有多个适合的数据库数据类型，信任hibernate选择默认值可能不是明智的做法。
3. 总是有一些特定于数据库的最佳实践，hibernate不会知道，但是DBA会知道。例如，如果要创建索引，则无法在hibernate注释中指定该索引，也无法指定要创建的索引类型，例如B-树、位图.等等。如果JPA/Hibernate注释得到了增强，允许您在数据库特定的DDL中指定所有选项，那么注释将比SQL更加复杂，因为SQL是构建非常好的域特定语言，而且注释永远不会像SQL那样好，它们将更加冗长。最后，你所做的就是在不降低复杂性的情况下改变复杂性。想想你遇到的所有基于XML的配置语言，它们最终增加了越来越多的复杂性，直到真正的编程语言用基于xml的循环完成，如果语句，变量.如果应用程序增长了，并且是一个成功的商业应用程序，拥有大量的数据，您最终需要雇用一个DBA来优化、优化和镜像数据库.etc DBA将知道其数据库的最佳实践，但可能不一定/可能不了解Hibernate，这将使DBA的生活更加复杂。DBA可以对数据库进行许多不影响基于hibernate的java代码的更改，您是否真的希望DBA更改hibernate代码以更改数据库设置。一旦DBA更改了数据库设置，现在您就有了两个版本的数据库--来自hibernate的可导出版本和生产版本，即真正的one?
4. Database设计最佳实践和面向对象的设计最佳实践并不相同。从对象设计数据库可能意味着一个伟大的OO设计，但不是一个伟大的DB设计，首先设计DB，然后Hibernate面向对象的代码可能意味着一个伟大的DB设计，但不是一个伟大的hibernate / OO设计。从哲学上讲，我更喜欢手工编写DDL，将自己置于数据库设计模式中，而不是OO设计模式。在一个成功的应用程序中，数据库设计可能比hibernate长很多年。仅仅因为hibernate是今天唯一与数据库对话的东西，并不意味着它将是将来唯一与数据库对话的东西。因此，我倾向于错误地使用数据库设计最佳实践而不是OO最佳实践来优化数据库设计。
5. Hibernate / ORM是漏泄的抽象，无法向开发人员隐藏您正在处理的SQL数据库的事实，如果您的开发人员对SQL不太了解，那么使用hibernate的方式将使数据库成为瓶颈。关于hibernate的个人经验培训告诉我，要有效地使用Hibernate，您必须更好地理解SQL。您需要能够检查HQL或其他对象查询语言，并将其从精神上转换为SQL。您需要知道何时可以映射关系并使用报表查询遍历它们。您将需要理解为什么查询中的联接丢失是这样一个问题。我是ORM/Hibernate的忠实粉丝，我可以有效地使用它，但我发现许多开发人员低估了使用ORM工具(如hibernate.
6. The )的复杂性/复杂性--如果我正在编写一个丢弃的原型，并且我对数据库特定的DDL不太了解的话，可能会导致我导出模式的异常。但是，我并没有遇到过很多扔掉的原型，这些原型并没有一下子变成永久的。

这些是我反对从Hibernate注释中生成DDL的理由。我希望其他人能与他们的想法和经验相契合。