Store a variable amount of information in SQL Server

Question

Suppose I have a table with users, called Users . These users all have user profiles. These profiles are stored in a table called UserProfiles .

I then have a table called Settings , which is there for the purpose of storing whether or not a button should be shown to any given user, based on the user's profile.

As it is done now, in the Settings table, I have a two columns, a key and a value, with the value being a string.

The string is then all the user profile ids separated by a ; like this: 1,4,16,2

I don't feel like this is a viable solution in the long run, but I'm having a hard time figuring out how to solve it otherwise.

One way would be to have a table for the button called 'ShowButtonName' and then store have an entry consisting of a userprofileid and a boolean telling if the button should be shown for that userprofile.

Any pointers would be helpful :-)

EDIT:

To expand on my question, here is my current design

Users:

- Id / PK
- UserprofileId / FK to Userprofiles.Id
- PinCode
- Username
- CardCode
- RawCode
- PukCode

Settings:

- Id / PK
- Name
- Value

Userprofiles:

- Id / PK
- Name

Users and Userprofiles have a one-to-many relationship in that multiple users can have the same userprofile.

EDIT:

I came up with this idea. Add a new table called UserprofileSettings

That table would then look like this

UserProfileSettings:

- Id / PK
- UserprofileId / FK to Userprofiles.Id
- ShowCleaningBtn / true/false
- ShowUserBtn / true/false
- ShowLogBtn / true/false
- ShowStatuspanel / true/false

How does that solution look like to you?

Answer 1

SQL has two data types that are designed for holding multiple values - unlike strings where you can only achieve this by inventing more structure (eg delimiters, escaping machanisms and/or fixed widths) and imposing that on the string. Of course, then, SQL Server doesn't help you in accessing these "multiple" values because it has no knowledge of your encoding scheme.

The two types that are designed for holding multiple values are the XML type and tables. Tables are, generally, the best way to stored multiple values, and most of the best tools in SQL Server are there to help you get the best out of using tables.

Now, as to whether you store your data as multiple columns or multiple rows within your table comes down to how the data is actually being used. If you end up with multiple columns with the same prefix and a different suffix (or vice versa), it's usually an indication that the model is wrong - those unique parts of the names probably ought to be data , not metadata .

So, you're proposed model:

ShowCleaningBtn / true/false
ShowUserBtn / true/false
ShowLogBtn / true/false
ShowStatuspanel / true/false

feels somewhat wrong. I'd rather have the button name as one column, and an appropriate other name for the column that now stored true or false, eg:

UserprofileId / FK to Userprofiles.Id
ControlName
Visible
Enabled

And other columns that might store relevant state for the control. And then it will have one row for the CleaningBtn , one row for the LogBtn , etc.

If there are certain controls that require a lot of settings, then either an additional table containing those settings and referring back to this one, or sparse columns might be considered. Or again, you might consider an extra xml extension column that stores such settings - but only if you're unlikely to want to query for this data directly in SQL.

Answer 2

You should not store id s in strings. That is a bad format for databases, and particularly difficult for SQL Server to work with.

You want one row for each id , so a table with columns like:

• UserId
• SettingsKey

You might also have additional columns such as:

• IsActive
• ActivationDate
• UserSettingsId -- an identity column to uniquely identify each row

Unless you are working with many millions of users/setting combinations, you don't need to worry much about performance (although indexes will probably be necessary for the queries you want to run).

Answer 3

Sounds like a typical many to many relationship which would normally be implemented with a link table. Hope you don't mind but I've renamed your table Settings as Permissions and UserPermissions which is more in keeping with what you're doing. The table structure would be something like this...

Users
- Id / PK
- UserprofileId / FK to Userprofiles.Id
- PinCode
- Username
- CardCode
- RawCode
- PukCode

Permissions
- Id
- Name
- Type (Class of Permission e.g. Screen, Action. Or finer granularity of ReadAddress, WriteAddress)

UserPermissions
- Id
- UserId
- PermissionId
- Level (Explicitly Granted or denied or null for default)

Also not sure if your Profile is really a Role where a user can only be included in a single role. If this is the case it would simplify things to have Permissions assigned to the ProfileId (RoleId) then you're not having to bother with maintaining against every user just every profile/role.

Hope that makes sense.