SQL Table and C# Enumeration

Question

Suppose I have n types of users in my application.

I am using an UserType enumeration to distinguish them.

Do I need to keep a table in

Answer 1

I would do that. I would create a separate table which contains all the possible usertypes. By doing so, you'll keep an eye on the integrity of your data at the DB level.

Why would it make your code somewhat complicated ? I do not understand that.

Answer 2

Yes, use both: UserType lookup table and enumeration

For the sake of understanding data structures we do create lookup tables with defined types even though they never change. This way you keep referential integrity by also relating tables to this lookup.

Automate your enums
By using T4 templates you can easily automate your business layer code to reflect DB changes. So whenever you change your SQL script to change values in your lookup table, you just run your templates and create additional values in your enums. And BTW: all T4 templates can be executed with a single click in Visual Studio 2008. Select your solution in Solution Explorer and click an icon in the mini toolbar of Solution Explorer. Voila. T4s all generated.

Flag enums
They are all fine and dandy, but it complicates T-SQL scripts in case you would also use them in the same way as in your business layer. Maybe it is more wise to use many-many relationship instead, but you won't be able to automate enum creation, so making a change on DB layer would also mean making a change on business layer.

Answer 3

Often in practice you have a table in the database and the corresponding enumeration in the source code.

Enumeration makes it easy for you to work with values that otherwise would not have sense to you.

Having a table in the database lets you perform queries and see in results values that make sense + enforce data integrity (foreign keys).

The challenge here is to keep the table values synchronized with those of the enumeration. But it works well in practice.

Answer 4

You can set this as an int column in the database, and then use the Flags() attribute for your enumeration. You're limited to 32 UserTypes (2^32) however.

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

Update
I skipped the part about not wanting to read through the source. How is the source using the enumeration? If it's using the number then the look-up table won't affect performance and is a good idea for reference. If the application is using a string name, then maybe it would be easier to adopt the ASP.NET roles provider (iirc) technique of simply using an indexed varchar column for UserType, on the user table.

So:

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

There can still have a reference table if needed.

I stick to the enumeration solution in the code, but that's because on most of the projects I'm involved with the roles list is static. So if the roles do need to be customisable then a separate look-up table would be the best option, but still using the flags system mentioned above (instead of an intermediate many-to-many table).

Also for a large amount of users, the de-normalized Flags system would be preferable and I'd guess faster. Do you care enough about 3rd normal form for the many-to-many way (but one that ensures better referential integrity). The comma separated list of roles would probably be just as fast and less cumbersome to manage for a small set of users.