Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Chapter 8: Being Normal: Normalization and Other Basic Design Issues
Let’s move on now to our second example — one where we create an associate table from scratch just so
we can have a many-to-many relationship. We’ll take the example of a user and a group of rights that a
user can have on the system.
We might start with a Permissions table that looks something like this:
PermissionID Description
1 Read
2 Insert
3 Update
4 Delete
Then we add a Users table:
UserID Full Name Password Active
JohnD John Doe Jfz9..nm3 1
SamS Sam Spade klk93)md 1
Now comes the problem — how do we define what users have which permissions? Our first inclination
might be to just add a column called Permissions to our Users table:
UserID Full Name Password Permissions Active
JohnD John Doe Jfz9..nm3 1 1
SamS Sam Spade klk93)md 3 1
This seems fine for only a split second, and then a question begs to be answered — what about when our
users have permission to do more than one thing?
In the older, flat file days, you might have just combined all the permissions into the one cell, like:
UserID Full Name Password Permissions Active
JohnD John Doe Jfz9..nm3 1,2,3 1
SamS Sam Spade klk93)md 1,2,3,43 1
233