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

Question

药膏！

关于SO another question/answer的一部分（以及声称相同的其他声明）：

  

如果您通过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实体。