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

药膏！

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

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

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

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

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

这不包括“特殊情况”，例如（业务逻辑）特定的INSERT触发器等，因为这些根本不能由JPA实现生成（据我所知，如果我错了，请纠正我）。

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

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

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

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

有几个原因我更喜欢手工维护模式：

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

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