管理数据库参考数据及其相关代码

Question

参考数据或查找表是CustomerType，ProductType等。它们不经常更改，偶尔会添加新类型或旧类型退役。在代码中，它们通常被复制为枚举/常量，并且还用于填充组合框。添加新类型不应该破坏现有应用程序，并且通常只需要这些新类型支持新应用程序的功能，遗留应用程序应该忽略它。

这种情况在大多数开发商店都会很熟悉，经过几年/几个月它会变得凌乱，不受控制，如果数据库和代码失去了步骤，就会发生不好的事情。

其他人如何处理此问题？代码/数据库是什么样的，它是如何版本化的？

Answer 1

您的意思是，ID和标签在代码中是硬编码的，和也出现在数据库的查找表中吗？

我们采用的方法是从数据库中读取“类型”ID和标签，并使用它们填充列表框。

（幸运的是）我不必支持需要从同一个查找表中读取不同值集的不同版本的应用程序。

我听说有人为查询表值分配最低版本ID。应用程序传递其版本（可能是1.5），并检索版本为1.5或更低的所有查找值。为应用程序的更高版本（例如2.1）添加的查找值将被忽略。

这显然会带来一些重要的维护开销。

Answer 2

我们创建了一个本土工具，在构建期间运行一个或多个文件中指定的查询，并生成枚举类型类，每个引用数据表对应一个类。该工具至少需要参考数据表有两列：主键（具有唯一约束）和字符串。每个枚举实例都有一个从字符串生成的名称（在通过算法将名称转换为大写后，将空格和其他无效字符替换为下划线等）。

该工具足够灵活，可以为每个值提供额外的属性;例如，“显示名称”，“描述”，可能是相关的数值，以及其他简单类型。我们还在枚举类上生成静态方法以获取各种值的子集;总是至少有一个返回所有值，但我们可以根据SQL查询生成其他值。对于颜色枚举，我们可能有一个“primaryColors（）”静态方法。生成其他静态方法以根据其键查找值;如，

public static Color valueOf(int key);

枚举使代码中使用众所周知的参考值变得容易且可读性更高;如，

if (selectedColor == Colors.RED) {
   .
   .
   .

}

这确实有一个缺点，需要额外的构建步骤，但在我们的情况下，远远超过优势：更清晰的代码，保证UI，业务逻辑和数据库有效值同步等等。

我们经常谈到如上所述的静态机制的混合以及添加更多动态行为，但我们从未真正觉得它足以引起复杂性。