我的问题更具体的是:
我希望多个前端的用户能够看到数据库行的“类型”。简单地说,我有一个人员表,类型可以是 Student
、Teacher
、Parent
等。
具体的程序将是带有 hibernate 的 java,但是我怀疑这对于这个问题来说很重要,但是假设我的数据被建模为 Entity beans,并且 Person“type”字段是一个包含我的 3 个选项的枚举,理想情况下我希望我的 Person 对象有一个 getType()
方法,我的前端可以使用该方法来显示类型,并且我还需要一种方法让我的前端了解潜在的类型。
使用枚举方法,我拥有此功能,但我没有的是无需重新编译即可轻松添加新类型的能力。
所以接下来的想法是,我将类型放入配置文件中,并将它们作为字符串简单地记录在数据库中。我的 getType() 方法有效,但现在我的前端必须加载一个配置文件来获取潜在的类型,现在没有任何东西可以使它们保持同步,我可以从我的配置文件中删除一个类型,然后数据库中的类型将不指向任何内容。我也不喜欢这个。
最后的想法是我创建一个 PersonTypes 数据库表,该表有一个用于 type_id
的数字和一个定义类型的 string
。这是可以的,如果设置了外键,我无法删除我正在使用的类型,我的前端将需要看到潜在的类型,我想最好的方法是提供一个将使用 hibernate 层来执行此操作。
此方法的问题在于,我的类型在数据库中都是英文的,并且我希望我的应用程序支持多种语言(最终),因此我需要某种属性文件来存储类型的标签。那么我是否有一个仅包含整数的 PersonType
表,然后是一个描述每个整数标签的属性文件?这似乎是倒退?
是否有通用的设计模式来实现这种行为?或者谁能建议一个好方法来做到这一点?
问候,
格伦x
最佳答案
我会采用您描述的最后一种方法。将类型信息放在单独的表中应该足够好了,它可以让您利用 SQL 的所有优势来管理附加约束(类型可能是唯一的,外键检查将确保您在删除时不会引入任何不当行为)一些记录)。
当每种类型都在属性文件中定义了 i18n
值时,那么您就安全了。如果类型被删除 - 该值将不会被使用。如果需要,您可以在运行时更改属性文件。
我能想到的最后一种方法是将 i18n
字符串与类型信息一起存储在 PersonType
中。这对于少量语言来说是可以接受的,尽管可能被认为是反模式。但它会让你有这样的方法:
public String getName(PersonType type, Locale loc) {
if (loc.equals(Locale.EN)) {
return type.getEnglishName();
} else if (loc.equals(Locale.DE)){
return type.getGermanName();
} else {
return type.getDefaultName();
}
}
关于java - 在具有潜在多语言需求的数据库中定义 "types"的最佳实践设计模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9210764/