最佳实践：JPA 的最佳数据库命名约定？ [关闭]答案

【问题标题】：Best practice: best database naming convention for JPA? [closed]最佳实践：JPA 的最佳数据库命名约定？ [关闭]
【发布时间】：2010-10-15 18:33:51
【问题描述】：

在 Java 中，属性和类（实体）的命名约定以 CamelCase 方式完成：

@Entity 
public class UserMessage implements Serializable { 
    @Id 
    private Integer id; 
    private String shortTitle;
    private String longTitle;
    private String htmlMessage; 
}

但在 SQL 世界中，best practice 在单词之间使用带有下划线的大写字母（如 Java 常量）。在 SQL 世界中，将表名包含在列名中也被认为是一种最佳实践，这样在大多数情况下外键的命名与原始表中的 id 完全相同。

CREATE TABLE USER_MESSAGE (
    USER_MESSAGE_ID  MEDIUMINT(8) NOT NULL,
    USER_MESSAGE_SHORT_TITLE VARCHAR(20),
    USER_MESSAGE_LONG_TITLE VARCHAR(80),
    USER_MESSAGE_HTML_MESSAGE TEXT NOT NULL
);

我应该同时遵循这两个标准并在@Table 和@Column 上使用name 属性吗？或者我应该遵循 Java 约定并依赖默认的 JPA 映射。

对于这种标准冲突，最常见的方法和/或最佳方法是什么？

【问题讨论】：

“我是否应该同时遵循这两个标准并在@Table 和@Column 上使用name 属性”。这是你的答案。让注释发挥作用。
我不确定我是否真的同意这种看起来很生气的命名约定在“SQL 世界”中被认为是“最佳实践”。只是说...

标签： java sql hibernate jpa naming-conventions

【解决方案1】：

我应该同时遵循这两个标准并在@Table 和@Column 上使用name 属性吗？或者我应该遵循 Java 约定并依赖默认的 JPA 映射。

如果 JPA 默认约定与贵公司的首选约定不匹配（没有“一个真正的”标准），请覆盖它们。这可以使用@Table 和@Column 注释来完成（在Hibernate 的特定情况下，您也可以提供自己的implementation of a NamingStrategy）。

对于这种标准冲突，最常见的方法和/或最佳方法是什么？

没有冲突，有 Java 命名约定，在 JPA 端有一个默认约定用于将对象映射到表（因为 JPA 必须选择一个）并且 那里在 SQL 方面没有“一个真正的”标准。所以：

如果您的公司没有任何 SQL 命名约定，您可以使用 JPA 约定
- 如果您不喜欢它们，请覆盖它们
如果您的公司有约定，请遵循它们并覆盖 JPA 默认值

【讨论】：

谢谢帕斯卡。另一个：您将如何处理由于数据库中不存在包命名空间而引起的命名冲突？例如：你有一个实体 app.model.forum.Post 和 app.model.blog.Post。您是否会将这些类重命名为诸如 ForumPost 和 BlogPost 之类的唯一名称，以便它们可以引用相同的表名？如何最好地解决这个命名空间冲突？
@Kdeveloper 如果您决定依赖 JPA 默认值，那么您必须使用不同的实体名称，就像在您的示例中一样（这也将使查询更容易）。

【解决方案2】：

我想这取决于您指的是谁的约定。我没有将表名放入列名中——为了重复你已经知道的内容而丢失一半的命名空间有什么意义？我（尝试）遵循的（一些）规则是：

长而有意义的名称比短名称更好，例如TRANSACTION_DATE 而不是 TRAN_DT。是的，当您仅限于 6 个字符的变量名时，我已经足够大，可以编写 Fortran，而且我记得您只有 A-Z、A0-Z0...A9-Z9 的基本变体——但我也足够老了学得更好。用于索引等的单字符变量名很好 - 实际上是传统的 - 但是当我找到一个具有十二个单字母变量名的函数时，每个变量名都用于多种用途，我......不开心。
李>
人工主键命名为 ID_>。
单字段自然数据主键是最好的。两字段自然主键是可以的。三个或更多字段 - 创建一个人工主键并使自然键成为备用唯一键。
您永远，永远，永远不能指望日期、时间或日期/时间字段是唯一的。曾经。不要忘记这一点。我是认真的。
混淆编码技术等同于无能。

我敢肯定还有更多，但这是一个开始。所有恕我直言。 YMMV。

分享和享受。

【讨论】：

【解决方案3】：

两者都关注。为了 DBA 和思维定势不同的手动报告和查询，应该存在 db 约定。使用注解上的名称参数来实现这一点。

【讨论】：

【解决方案4】：

就我而言，两者都可以接受。但是，如果您决定不使用默认的驼峰式大小写，则可以采用不同的命名策略，而无需为每个注释添加名称属性这一繁琐且容易出错的任务。

看看 Hibernate 的 org.hibernate.cfg.ImprovedNamingStrategy 类。它使用下划线而不是驼峰式大小写。只需在 Hibernate 配置上设置一个属性即可使用它。

如果你真的想要，你也可以扩展 ImprovementNamingStrategy 来添加表名或全部大写，但这似乎没有必要。

【讨论】：