Question

技术： - Java 1.5或1.6 - Hibernate 3.4

为避免在更改列名或表名时更改多个位置的列名，我希望有一个常量文件。

我有以下疑问？

在上述情况下，employees是表的名称，performance_desc是列名的名称。因此，为了避免两个不同表的两个常量之间发生冲突（如果两个表都有列名），请遵循tablename__columnname格式，以避免发生冲突。

我看到这种方法的一个问题是，随着数据库的增长，此文件中的常量不会增加到数千个，这很难管理。其他问题是如果更改了表名，我必须更改所有表的前缀表名。

假设我将上述示例中的列名称从performance_desc更改为achievement_desc。在这种情况下，我很可能也希望改变常数，即从EMPLOYEE__PERFORMANCE_DESC到EMPLOYEE__ACHIEVEMENT_DESC。因为在这种情况下我需要更改列名和常量名称我没有看到在我的代码中直接使用常量而不是列名的使用尽管有一个好处，在更改常量名称时我可以使用折射来反映常量名称名称在引用的地方更改。似乎使用常量的用法不多，或者我使用错误的方法。
在项目代码中，我似乎有人为每个表列列表定义一个类来定义常量，如下所示。
```
public class tbl_Employee
{
        public static final PERFORMANCE_DESC=performance_desc;
}    
```

这可以解决一些与全局文件一样的问题，比如表名更改只会导致类名更改。这个问题的一个主要问题是我使用类仅用于定义不是良好编码实践的常量。

使用值字符串读取一些关于Enum的地方而不是int，不确定它是否可用于java 1.5或1.6以及是否建议在给定方案中使用。
给定定义db常量的最佳做法是什么？
使用db常量真的很有用吗？
如果我像上面提到的那样为每个表使用一个类，我面临的一个问题是命名约定。表的名称和对应的类名称之间应该有什么关系，它们定义表的列的常量。
以上案例仅涵盖列名而非表名的情况。我可能喜欢在代码中使用常量而不是表名，因此应该采用什么方法来定义表名的常量。
经常有人认为，一旦产品或相关版本发布，表名和列名就不会有太大变化。表名和列名的更改主要发生在开发阶段或功能增强（新版本）期间。避免对表名或列名使用常量是否是强有力的论据？

请建议我如何才能使我的问题更具代表性，或者我的遗失是什么？我的问题未被投票？

Answer 1

听起来你问的是所有正确的问题 - 你想让代码更易于维护，但是要意识到这可能会变得难以操作并最终使代码变得更糟而不是更好。想想像“Color.RED，Color.BLACK”这样的东西。

我发现像这样的合理的常量会使代码更具可读性。我不认为db列名称属于这样的东西，因为

我已经看到像这样的db文件有数千个常量，包括自定义查询，部分查询等等（甚至像public static final String COMMA=",";这样的宝石来处理逗号的拼写会改变的可能性在将来）。在这一点上，他们转向“使用一次”字符串，没有人敢改变它们。

关于字符串常量的另一个警告 - 韵母作为字符串被编译到你的类中。因此，如果您重新编译常量类，而不是使用该定义的类，则最终可能不会传播新定义。

Answer 2

您是否考虑过使用实体映射框架（如Hibernate）？

它可以将所有数据库表信息（以及所有其他数据库特定信息）存储在配置文件中。它还在“硬”DB设计和您的应用程序之间提供了一个分离层（这样可以更容易地吸收对它们的更改）。

Answer 3

您可以创建一个定义常量的接口。

Answer 4

在我目前的项目中，我们正在大量使用annotations来处理很多与数据库相关的元数据，因为我们不能使用像Hibernate这样的框架。对于实际的列常量，是的，我们使用久经考验的public static final String。是的，它相当脆弱。

Answer 5

当我有关于数据库的元数据时，我也会将其存储在数据库中。这是我看到其他系统运行的方式，如果不是最初那么最终。为确保维护此数据，您可以检查数据库的架构。