是的，同时使用：UserType查找表和枚举

为了理解数据结构，我们确实创建了具有已定义类型的查找表，即使它们永远不会更改。这样，您还可以通过将表与此查找相关联来保持参照完整性。

自动化您的枚举
通过using T4 templates，您可以轻松自动化业务层代码以反映数据库更改。因此，每当您更改SQL脚本以更改查找表中的值时，您只需运行模板并在枚举中创建其他值。 BTW：只需在Visual Studio 2008中单击即可执行所有T4模板。在解决方案资源管理器中选择您的解决方案，然后单击解决方案资源管理器的迷你工具栏中的图标。瞧。 T4都生成了。

举报举报
它们都很好用，但它会使T-SQL脚本变得复杂，以防你以与业务层相同的方式使用它们。也许使用多对多关系更明智，但是你无法自动创建枚举，因此在数据库层上进行更改也意味着在业务层上进行更改。

Answer 2

通常在实践中，您在数据库中有一个表，并在源代码中有相应的枚举。

枚举使您可以轻松使用对您没有任何意义的值。

在数据库中使用表可以执行查询并查看结果中有意义的值+强制执行数据完整性（外键）。

这里的挑战是保持表值与枚举的值同步。但它在实践中运作良好。

Answer 3

您可以将其设置为数据库中的int列，然后使用Flags()属性进行枚举。但是，你只限于32 UserTypes（2 ^ 32）。

[Flags]
public enum UserType
{
    None = 0,
    Viewer = 1,
    ContentEditor = 2,
    Editor = 4,
    Admin = 8,
    Root = 16,
    Disciple = 32,
    God = 64
}

<强>更新
我跳过了关于不想阅读源代码的部分。源如何使用枚举？如果它使用的是数字，那么查找表不会影响性能，是一个很好的参考。如果应用程序使用字符串名称，则可能更容易采用ASP.NET角色提供程序（iirc）技术，只需在用户表上使用UserType的索引varchar列。

所以：

Name    Email           UserType
Bob     blah@blah.com   admin,author

如果需要，仍然可以有参考表。

我坚持使用代码中的枚举解决方案，但这是因为我参与角色列表的大部分项目都是静态的。因此，如果角色确实需要可自定义，那么单独的查找表将是最佳选择，但仍然使用上面提到的标志系统（而不是中间的多对多表）。

同样对于大量用户来说，非标准化的Flags系统会更好，我猜的更快。您是否足够关注多对多方式的第三范式（但确保更好的参照完整性）。逗号分隔的角色列表可能对于一小组用户来说同样快速且不那么麻烦。

Answer 4

我会这样做。我将创建一个单独的表，其中包含所有可能的usertypes。通过这样做，您将在数据库级别密切关注数据的完整性。

为什么会让你的代码变得复杂？我不明白。

SQL表和C＃枚举

4 个答案:

是的，同时使用：UserType查找表和枚举