Question

我想知道您的开发商店或项目中处理查找值的协议是什么，例如世界各国或美利坚合众国的州。

我看到它以两种不同的方式完成：在我工作的一个地方，我们的查找都存储在一个带有前缀“L_”的数据库表中，并有以下列：id，code，desc，ordersequence。因此，例如，对于世界各国，我们会有一个表格：

CREATE TABLE L_Countries(

   CountryID INT IDENTITY(1,1) PRIMARY KEY, 

   CountryCode VARCHAR(10) NOT NULL, 

   CountryDesc VARCHAR(50) NOT NULL, 

   OrderSequence INT NULL

)

最近我看到了一个例子，其中查找被包含在Enumerations中，例如：

enum Countries 
{

  Croatia = 1, 

  Slovenia = 2, 

  Serbia = 3, 

  // and so on  

}

如果这些源自数据库表，则有一个实用程序将为枚举生成C＃代码。否则，有人只是花时间硬编码所有条目，假设值不太可能改变。对于枚举中的数值，它们基于数据库中相应查找表中的ID列进行硬编码（如果存在），或者仅根据从1开始的条目进行硬编码。

前一种方法的论据，无论如何，我赞成，它是非常灵活的，可以选择使用代码或完整描述，操纵顺序，无需重新编译即可进行更改。虽然可以选择从它们生成代码，但是一个很大的优点是它们在降级到数据库时仍然是真正的“查找”。最后，它们的使用方式是灵活的：作为Dictionary集合中的值或使用服务器端代码生成ASP.NET ListItems或html组合框元素。

我听说后者的论点是值不会改变，并且即使它们在应用程序级别缓存，也必须从数据库中检索查找值。通过对它们进行硬编码或生成枚举，它们可以在没有数据库检索的情况下使用。

我的问题如下：

哪个选项对您更有意义，或者，如果您的答案是“它取决于”，您是否可以给出一个场景，其中硬编码的枚举优于整个应用程序中的数据库查找？
您是否还有其他方式可以看到哪些是处理查找的优雅解决方案？我曾经在一个应用程序上工作，其中有一个表用于所有查找（它包括一个“lookupname”列）作为示例。您的替代方法与上述两种方法相比如何？

Answer 1

如果信息非常静态并用于流量控制等，我会使用枚举（即我们将它们用于医疗表格类型，医疗表格上的各种选项等）。

如果信息是静态的但是更大，或者通过使其成为枚举而没有提供任何价值或表现力，并且连接不需要它等，我们将其存储在XML或哈希表中并根据需要读取它和/或嵌入资源。

如果要在数据库连接中使用该信息，过大，或者将它存储在数据库查找表中更为实际，我们这样做，通常使用int作为主键。

希望有所帮助

Answer 2

这些方法并不相互排斥。我使用CodeDom从数据库表中自动生成枚举代码。有一个引导问题（即如何填充和管理数据库本身），但您可以在构建步骤中生成枚举，从而确保两者永远不会失去同步。

Answer 3

国家/地区代码的ISO标准是2或3个字符。国家/地区的ISO标准是40个字符。 ISO还为所有国家/地区指定数字标识符。

我认为在此表中使用IDENTITY作为键是没有意义的，因为显然需要在设计时为ENUM生成值，而不是在运行时插入。除非以某种方式使用它，否则我建议您删除IDENTITY属性并使国家/地区代码唯一。从数据完整性的角度来看，设计很薄弱，因为它缺乏自然键。

设计查找值

3 个答案: