Wrox Programmer Forums
|
SQL Server 2000 General discussion of Microsoft SQL Server -- for topics that don't fit in one of the more specific SQL Server forums. version 2000 only. There's a new forum for SQL Server 2005.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the SQL Server 2000 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old April 30th, 2004, 03:23 PM
Authorized User
 
Join Date: Apr 2004
Posts: 20
Thanks: 0
Thanked 0 Times in 0 Posts
Default Design question?

Hi,

I am new to Databases and I am currently designing a database that stores information relating to users.

In this application that I am developing at the time of registration the user is asked to enter a username and password that are being stored in a 'userinfo' datatable. Now after registering the user is given the option of storing multiple profiles under his/her login. Now my question is: Is it a good practice to have different tables for different users with each table storing profile information for a particular user or should all the profiles of all the users be stored in just one table. I would really appreciate it if anyone can let me know how to proceed.

Thanks in advance.
Qadeer.

 
Old April 30th, 2004, 03:49 PM
Friend of Wrox
 
Join Date: Nov 2003
Posts: 1,285
Thanks: 0
Thanked 2 Times in 2 Posts
Default

I would put all the users in the same table, I think (not sure) that it would save space.

HTH,

Snib

<><
 
Old April 30th, 2004, 05:58 PM
Registered User
 
Join Date: Apr 2004
Posts: 4
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via AIM to bizzeau Send a message via MSN to bizzeau
Default

For normalization practices, you should put all profiles for a specific user id in a separate table called "Profile".

For instance:

User:
UserID - PK
UserName

Profile:
ProfileID - PK
ProfileName
UserID - FK

With the setup above, you allow for data to be consistent and not redundant. If you put all possible profile options into one table, you are going to end up with one table that has multiple fields that may or may not be used - this will just take up space. If you create both tables separately, you can easily query them to find all profiles for an individual user.


Beau Frusetta
SQL Server DBA/Developer
Web/Desktop Application Developer
Unicorn Financial Services/Contractor For Hire
(480) 980-1611
bizzeau@hotmail.com
 
Old April 30th, 2004, 08:27 PM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 2,480
Thanks: 0
Thanked 1 Time in 1 Post
Default

When you say, "different tables for different users", A table as such called a DOMAIN, a pool of values that are similar in function, so storing profiles/users information in different tables for each user is not a good practice.

Imagine if there are going to be 1000 users in your system, then you would face problem in finiding a relevant name for it. Would you go for creating different tables for different users? if the user count still grows, you got to keep creating tables for them, which is not recommended in anyway.

I would strongly suggest you to stick with "bizzeau's" recommendation.

Cheers!

-Vijay G
 
Old May 3rd, 2004, 10:17 AM
Authorized User
 
Join Date: Apr 2004
Posts: 20
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Thank you guys. I think I will follow bizzeau's recommendation.

Qadeer.






Similar Threads
Thread Thread Starter Forum Replies Last Post
design question androoo ADO.NET 1 November 13th, 2004 09:41 AM
design question androoo Classic ASP Databases 1 November 13th, 2004 09:41 AM
design question androoo General .NET 1 November 13th, 2004 09:40 AM
design question androoo .NET Web Services 1 November 13th, 2004 09:39 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.