使用JPA/ORM生成db模式是个坏主意吗？

Question

药膏!

关于SO 的另一个问题/答案的一部分(以及声称相同的其他陈述):

如果您通过JPA更新数据库模式(通常不是一个好习惯)

您是否应该使用JPA实现来生成数据库模式？

无论如何,我必须自己模拟实体和关系.我需要定义约束,例如notnull,主键和外键,数据类型和大小.

假设正在使用的JPA实现在其DDL模式创建代码中没有任何缺陷,并且假设我确实正确地指定了所有JPA约束,关系等,那么由JPA实现创建的db模式应该完全相同 - 如果不是更好 - 作为我自己手工制作的架构,对吧？

这不包括"特殊情况",例如(业务逻辑 - )特定的INSERT触发器等,因为这些根本不能由JPA实现生成(据我所知,如果我错了,请纠正我).

你对此有何看法？
我现在首先手工编写我的数据库模式,然后设置JPA约束,关系等,让JPA实现也创建一个数据库模式.然后我比较两个模式,看看我是否正确完成了设置.这当然意味着我还必须指定与我手工模式相同的列名等.

使我的问题更加准确; 我不会盲目相信ORM框架为我生成架构.我宁愿知道模式在我的脑海中如何看待,然后配置框架以匹配它.
我想你可以手工创建更多/最有效的架构,但毕竟我需要(或者更愿意)将它们与ORM框架一起使用.因此,虽然我不应该这样做,但在创建数据库模式时,我需要牢记ORM框架的局限性.

因此,我使用ORM框架以便不必关心RDBMS细节,让我的应用程序使用特定于RDBMS的DDL创建模式的重点是什么？
如果我必须使用一些现有的和异乎寻常的模式,我不需要(重新)创建模式,以及我可能无法使用这样的通用工具作为ORM框架.

Answer 1

我通常只让JPA创建架构.之后,我对其进行微调并手动维护.

有几个原因我更喜欢手工维护架构:

它允许在SQL代码中添加注释
它允许为表和列添加注释/描述
它允许指定表空间和JPA注释无法实现的其他内容
它允许在几个SQL文件之间分割模式(例如,每个表一个+约束一个)
它允许我在模式迁移脚本中重用模式创建脚本的某些部分.例如,如果我的应用程序的第2版引入了3个新表,我需要一个可以重用三个SQL文件的alter脚本来创建三个新表
我有时需要使用同义词来表示序列,而不是具体的序列
它让我选择主键约束的名称
可能还有其他一些我忘记的原因

Answer 2

我通常做相反的事情，即手动创建数据库模式，然后使用IDE从中导出JPA实体结构。然后，我再次手动完善JPA实体。