枚举与内部联接/在哪里答案

【问题标题】：Enum Vs Inner Join / Where枚举与内部联接/在哪里
【发布时间】：2012-09-26 16:43:51
【问题描述】：

我已经通过 int 定义了各种文本值。我将 int 值存储在数据表中以便更好更快地搜索。我有三个选项来显示文本值：

我在代码中声明了 Enum 并根据 int 值显示文本值。它是静态的，如果要添加新值，我必须更改代码。
为了使其动态化，我可以将 int 和 text 值存储在另一个数据库中的表中，并由管理员拥有它。管理员可以在此表中更新新值。每当获取记录时，我都会使用内部联接来显示文本值。
我将实际文本存储在相应的数据表中。这会使搜索变慢。

我的问题是在以下情况下哪个选项最好使用？

【问题讨论】：

【解决方案1】：

我喜欢选项 #2 和选项 #1 的组合 - 使用 int 但在另一个数据库中有字典表。
让我解释一下：

【讨论】：

【解决方案2】：

由于给出的原因，我不会选择选项 1。枚举不作为查找存在。您可以将 1 替换为创建字典，但每次进行更改时都需要重新编译它，这很糟糕。

如果保证像这里那样重复很多，那么将文本存储在表格中（即选项 3）是不好的。这正是您应该按照第 2 条建议使用查找表的地方。

所以是的，将它们存储在数据库表中并通过它来管理它们。

如果只是到一张小桌子，加入应该不需要很长时间。如果您担心，一种替代方法可能是在第一次需要时将查找表加载到代码中的字典中，并从您的小型查找表中查找代码中的值。不过，我怀疑你只是通过加入来做这件事会遇到问题。

无论条件如何（即记录数等），我都会采用这种方法。不过，条件确实使它更明智。 :)

【讨论】：

【解决方案3】：

如果您确实拥有数百万条记录，那么尝试在服务器代码中或以任何形式在客户端上构建这样的结构几乎肯定没有意义。它需要保存在数据库中，恕我直言。

创建列表的查询需要足够智能，以将返回记录的计数限制为可管理的数量。也许分区视图或存储过程可能在这方面有所帮助。

如果这主要是一个只读列表，并且仅在管理活动的上下文中进行更新，则应该可以在客户端使用适当的索引和查询非常快速地对表进行查询。

【讨论】：