2

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

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

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

我的问题如下：

  1. 哪个选项对您更有意义，或者，如果您的答案是“视情况而定”，您能否给出硬编码枚举优于跨整个应用程序的数据库查找的场景？

  2. 您还见过其他处理查找的优雅解决方案吗？我曾在一个应用程序中工作，其中所有查找都有一个表（它包括一个“查找名称”列）作为示例。您的替代方法与上述两种方法相比如何？

4

3 回答 3

1

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

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

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

希望有帮助

于 2010-12-01T20:03:32.600 回答
0

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

于 2010-12-01T20:07:46.670 回答
0

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

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

于 2010-12-01T20:46:16.943 回答