设计查找值答案

【问题标题】：Designing For Lookup Values设计查找值
【发布时间】：2011-05-18 17:29:43
【问题描述】：

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

我看到它以两种不同的方式完成：在我工作的一个地方，我们的查找都存储在一个带有前缀“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

)

最近我看到了一个将查找纳入枚举的示例，例如：

enum Countries 
{

  Croatia = 1, 

  Slovenia = 2, 

  Serbia = 3, 

  // and so on  

}

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

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

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

我的问题如下：

哪个选项对您更有意义，或者，如果您的回答是“视情况而定”，您能否给出硬编码枚举优于跨整个应用程序的数据库查找的场景？
您还见过其他处理查找的优雅解决方案吗？我曾在一个应用程序中工作，其中所有查找都有一个表（它包括一个“查找名称”列）作为示例。您的替代方法与上述两种方法相比如何？

【问题讨论】：

标签： database-design application-design lookup-tables

【解决方案1】：

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

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

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

希望有帮助

【讨论】：

【解决方案2】：

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

【讨论】：

【解决方案3】：

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

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

【讨论】：