views:

52

answers:

6

I am looking for an efficient way to store users' information in a SQL Server 2008 table.

In the design all users data will be stored in a series of columns in a single table but one of the columns requires to store a list of values, for example: 'column1' will store the username, 'column2' will store the userID and 'column3' will store a list of items that will change over time.

I want to avoid putting this information on a different table for each user because that would require a lot of tables in the database.

What data type should I use for this 'column3'? Should I use a completely different approach?

I see that on SQL Server we can use the table data type, but this seems to work only for temporary storage.

Thank you.

+3  A: 

I think you need a different approach.

If you are trying to model a many-to-one relationship then you should use an extra table with a foreign key constraint.

If you are trying to model a many-to-many relationship you can use three tables, with one table being a junction table that links the two other tables together.

If you are looking for a flexible schema you might want to consider an Entity-Attribute-Value approach. This design has its downsides but I think it's better than storing lots of different types of value in a single field.

Mark Byers
A: 

You can also use the XML type. Check here for more information.

Faisal Feroz
+2  A: 

Generally storing multiples values in column is an indication of poor database design. It makes it very difficult to efficiently select rows based on criteria within that single column. Having said that, if you really only ever need to select those values on a per row basis then consider using XML as SQL Server natively supports XML data.

Dan Diplo
+1  A: 

I want to avoid putting this information on a different table for each user because that would require a lot of tables in the database.

If I understand you correctly, and you want to store a list of items for each user, then it requires only one more table, not "a lot". Create a master table (Users) and a details table (UserItems), and add a foreign key column in UserItems that will point back to the owning Users record.

That is the proper way to design entity relationships in a relational database.

Allon Guralnek
Thank you Allon. In that case the UseItems table will have two colums: one to store the User and the other to store the associated item. That would mean a lot of repeated values on the user column like user1:item1, user1:item2, user1:item3, ... , userN:item1, userN:item2 and so on. To be honest, I am not sure if this is what is done in other applications but this is certainly a valid solution to the problem.
jorgepc
@jorgepc: Without some sample data, I can't intelligently talk about the example you gave.
Allon Guralnek
A: 

If you're using PHP, or another equally capable language, you could store the values as a delimited list, seperated with a special character like pipes ('|'), or even commas if you're sure they won't appear in the actual values you're storing. Extracting the values out would then be easy (in PHP at least) - simply do an $var = explode("delimiting_char", $input_string). You would end up with $var being an array of values. The delimiting_char would be your pipe or whatever you want to use.

Hope this helps (at least some)

JamWaffles
A: 

It looks like what you have in your requirement is to at the very least store a userID, username and a dynamic list of items for a user. You would need a schema which can hold the necessary information you need. A simple schema can allow for very fast retrieval and complex schemas can have a lot of integrity built in. There are pro's and con's for both different designs, and depending on what your requirement is, one schema design would work better than another.

Here are some examples that you can consider (user - item schema relationship):

many - many relationship schema

  • requires that a user to have at least one item list
  • if xml format changes many updates will be needed
  • users can have the same items as other users
  • will get you a list of items for a user without the need of any joins

    User
    userID
    userName
    Items (xml data type)

one - many relationship schema example

  • requires that a user to have at least one item list
  • restricts users having the same unique item

    User
    userID
    userName ListItemID

    List
    ListID
    ListItemID
    ItemID
    Item

one - many relationship schema example

  • restricts users having the same unique item
  • does not require a user to have one or many items

    User
    userID
    userName

    Item
    ItemID
    UserID
    Item

many - many relationship schema example

  • allows for a user to share the same item that other users have
  • it can be very fast to retrieve information
  • lots of redundant information. user and item information is stored multiple times
  • if the details of a user changes, you will need to make updates to one or many records
  • if the details of a item changes you will need to make updates to one or many records

    UserItems
    UserItemID
    userID
    userName
    ItemID
    Item

many - many relationship schema example:

  • this allows for a users to share the same unique item
  • does not require a user to have a list of items
  • it requires joining 3 tables to get information on the items the users have
  • if user information changes only 1 record to update
  • if the details of an item changes, only one record to update
  • if user item list changes, the number of changes would be the number of updates/deletes/inserts needed

    User
    userID userName

    ItemList
    ItemListID
    UserID
    ItemID

    Item
    ItemID
    Item

many - many relationship schema example:

  • this allows for a users to share the same unique item
  • requires that a user have a list of items (one or more)
  • it requires joining 3 tables to get information on the items the users have
  • if user information changes only 1 record to update
  • if the details of an item changes, only one record to update
  • if user item list changes, the number of changes would be the number of updates/deletes/inserts needed

    User
    userID userName ListItemID

    List
    ListID ListItemID
    UserID
    ItemID

    Item
    ItemID
    Item

Vijay Selvaraj
Thank you Vijay. This, along with Dan answer fits very well on what I intend to do.
jorgepc