java 最佳实践：JPA 的最佳数据库命名约定？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3945065/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Best practice: best database naming convention for JPA?
提问by Kdeveloper
In Java the naming convention for properties en classes (entities) are done the CamelCaseway:
在 Java 中，属性和类（实体）的命名约定以CamelCase方式完成：
@Entity
public class UserMessage implements Serializable {
@Id
private Integer id;
private String shortTitle;
private String longTitle;
private String htmlMessage;
}
But in the SQL world it's considered a best practiceto use upper case with underscores between words (like Java constants). In the SQL world is also considered a best practice to include the table name in the column names, this way foreign keys are in most cases named exactly the same as the id in the original table.
但是在 SQL 世界中，最好的做法是在单词之间使用带下划线的大写字母（如 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
);
Should I follow both standards and use the name attribute on @Table and @Column? Or should I follow the Java conventions and rely on the default JPA mappings.
我应该遵循这两个标准并在@Table 和@Column 上使用 name 属性吗？或者我应该遵循 Java 约定并依赖默认的 JPA 映射。
What is the most common approach and/or the best approach on this conflict of standards?
解决这种标准冲突的最常见方法和/或最佳方法是什么？
采纳答案by Pascal Thivent
Should I follow both standards and use the name attribute on @Table and @Column? Or should I follow the Java conventions and rely on the default JPA mappings.
我应该遵循这两个标准并在@Table 和@Column 上使用 name 属性吗？或者我应该遵循 Java 约定并依赖默认的 JPA 映射。
If the JPA default conventions don't match the preferredconventions of your company (there is no "one true" standard), override them. This can be done using the @Tableand @Columnannotations (in the particular case of Hibernate, you could also provide your own implementation of a NamingStrategy).
如果 JPA 默认约定与您公司的首选约定不匹配（没有“一个真正的”标准），请覆盖它们。这可以使用@Table和@Column注释来完成（在 Hibernate 的特殊情况下，您也可以提供自己 的 a 实现NamingStrategy）。
What is the most common approach and/or the best approach on this conflict of standards?
解决这种标准冲突的最常见方法和/或最佳方法是什么？
There is no conflict, there are Java naming conventions, there is onedefault convention on the JPA side for the mapping of objects to tables (because JPA had to pick one) and there is no "one true" standard on the SQL side. So:
没有冲突，有 Java 命名约定，在 JPA 端有一个默认约定用于将对象映射到表（因为 JPA 必须选择一个）并且在 SQL 端没有“one true”标准。所以：
- if your company doesn't have any SQL naming conventions, you could use the JPA conventions
- if you don't like them, override them
- if your company has conventions in place, follow them and override the JPA defaults
- 如果您的公司没有任何 SQL 命名约定，您可以使用 JPA 约定
- 如果你不喜欢它们，覆盖它们
- 如果您的公司有约定，请遵循它们并覆盖 JPA 默认值
回答by Steven
Follow both. The db convention should be there for DBA sake and manual reports and queries where the mind set is different. Use the name params on annotations to achieve this.
两个都跟着。数据库约定应该是为了 DBA 以及在思维定势不同的情况下进行手动报告和查询。在注释上使用名称参数来实现这一点。
回答by Bob Jarvis - Reinstate Monica
I suppose that this depends on whose conventions you're referring to. I do not put the table name into the column name - what's the point of losing half your namespace just to repeat what you already know? (Some of) the rules I (try to) follow are:
我想这取决于您所指的约定。我没有将表名放入列名中——为了重复你已经知道的内容而失去一半的命名空间有什么意义？我（尝试）遵循的（部分）规则是：
Long, meaningful names are better than short names, e.g. TRANSACTION_DATE rather than TRAN_DT. Yes, I'm old enough to have written Fortran when you were limited to 6-character variable names, and I recall Basic variants where you only had A-Z, A0-Z0...A9-Z9 - but I'm also old enough to have learned better. Single-character variable names for indices, etc, are fine - and in fact traditional - but when I find a function with twelve single-letter variable names each used for multiple purposes I...am not amused.
Artificial primary keys are named ID_<<"name of table">>.
Single-field natural data primary keys are best. Two-field natural primary keys are OK. Three or more fields - create an artificial primary key and make the natural key an alternate unique key.
Thou shalt never, ever, ever count on a date, time, or date/time field to be unique. Ever. Don't forget this. I mean it.
Obfuscatory coding techniques are equivalent to incompetence.
长而有意义的名称比短名称更好，例如 TRANSACTION_DATE 而不是 TRAN_DT。是的，当您被限制为 6 个字符的变量名称时，我已经足够大了，可以编写 Fortran，而且我记得您只有 AZ、A0-Z0...A9-Z9 的基本变体 - 但我也足够大了学得更好。索引等的单字符变量名很好 - 实际上是传统的 - 但是当我找到一个具有 12 个单字母变量名的函数时，每个变量名都用于多种用途，我......并没有感到好笑。
人工主键被命名为 ID_<<“表名”>>。
单字段自然数据主键最好。二字段自然主键就可以了。三个或更多字段 - 创建一个人工主键并使自然键成为备用唯一键。
您永远都不应将日期、时间或日期/时间字段视为唯一的。曾经。不要忘记这一点。我是认真的。
混淆编码技术相当于无能。
I'm sure there's more, but it's a start. All IMHO. YMMV.
我相信还有更多，但这是一个开始。所有恕我直言。天啊。
Share and enjoy.
分享和享受。
回答by Jeff
As far as I'm concerned either are acceptable. But if you decide you don't want the default camel case, you CAN get a different naming strategy without resorting to the tedious and error-prone task of adding the name attribute to every annotation.
就我而言，两者都是可以接受的。但是，如果您决定不想要默认的驼峰式大小写，您可以获得不同的命名策略，而无需求助于将名称属性添加到每个注释的繁琐且容易出错的任务。
Take a look at Hibernate's org.hibernate.cfg.ImprovedNamingStrategy class. It uses underscores instead of camel case. It is simply a matter of setting a property on your Hibernate configuration to use it.
看看 Hibernate 的 org.hibernate.cfg.ImprovedNamingStrategy 类。它使用下划线而不是驼峰式大小写。只需在 Hibernate 配置上设置一个属性即可使用它。
You could also extend the ImprovedNamingStrategy to prepend the table name or do all uppercase if you really want, but that seems unnecessary.
如果您真的需要，您还可以扩展改进的NamingStrategy 以预先添加表名或全部大写，但这似乎没有必要。
