Java 在hibernate实体中保留DB约束好吗

当我重构一个代码库时，我通过hibernate注释，比如

@Column(name = "personal_email", nullable = true, length = 64)
private String personalEmail;

在用户实体中。。。如果personalEmail超过64个字符，则实际上存在数据截断错误

我个人认为这样保留注释是一种糟糕的做法。我认为我们不必通过数据库实体元信息破坏代码

我的方法是删除长度和可为空的注释名称，并让DB在任何违反约束的情况下发出通知

我认为保留这种注释的唯一优点是它不会将错误数据传播到DB级别

我想知道你的建议

---

无论如何，我会在DB中更改personalEmail的列宽。

这取决于您更信任哪个系统。Hibernate（Java）或您的数据库

也许这份清单会对你有所帮助

Hibernate的优势

• 就是在同一个代码库中跟踪约束。不会在两个系统之间切换以检查它们
• 请随时为用户和您自己的日志文件提供更详细的信息

冬眠的不利条件

• 必须编译每个约束修改。没有可能的运行时更改，因此需要更多的维护（服务器重启等）

数据库的优势

• 您可以从JavaEE/JavaSE更改为任何其他系统

• 如有必要，在运行时进行约束更改（请注意，不建议这样做）

数据库的缺点

• 不在同一个代码库中。违规行为可能很难发现

• 用Java编写更多代码来翻译更具体的用户信息。数据库日志对用户不友好

---

实际上，这取决于您是否要通过hibernate创建数据库模式。如果没有，那么拥有注释就没有什么好处（可能只是为了提供信息）。我在考虑改变约束，而运行时不应该这样做。很抱歉，我不太明白你的意思。我实际上认为在运行时更改约束是可能的。但不应该这样做。因为可能有一些原因会导致关键行为，特别是在生产系统中。stackexchange链接后面有详细说明。大约7年前，Collegeus警告我在没有维护步骤（尤其是数据库备份）的情况下更改MS SQL约束。我不知道这与我的评论有什么关系。在生产环境中更改数据库肯定是有风险的，但这仍然是可能的。在任何情况下，当涉及到约束时，数据库是“主”数据库，如果您想让Hibernate生成模式而不是自己生成模式，那么JPA注释主要是有用的。