SQL表和C#枚举

假设我的应用程序中有n种类型的用户。

我使用UserType枚举来区分它们。

我是否需要在名为UserType的数据库中保留一个表?

这样我就可以通过查询表而不是搜索应用程序源代码随时找到用户类型。

这样做我的源代码可能会变得有些复杂。

我应该承认这种交易吗?

是的,同时使用:UserType查找表和枚举

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

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

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

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

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

在数据库中拥有一个表可以让您执行查询并查看结果中有意义的值+强制数据完整性(外键)。

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

您可以将其设置为数据库中的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系统会更好,我猜的更快。 您是否足够关注多对多方式的第三范式(但确保更好的参照完整性)。 以逗号分隔的角色列表可能对于一小组用户来说管理起来同样快速且不那么麻烦。

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

为什么它会使你的代码有点复杂? 我不明白这个。