Database design question.

Results 1 to 3 of 3

Thread: Database design question.

  1. #1
    Join Date
    Dec 1969

    Default Database design question.

    What would be the best way to design the following. In an application Im about to start developing there are going to be a bunch of different types of users.<BR><BR>All of these will probably have the same types of fields. <BR>firstname lastname etc. But some of these users will be tied into a company. Some will not. The question is.. Should I treat the company as a seperate entity? That is should I have a companies table? And then in the users table use a CompanyID? Or is it better to just store company information in with the user information as a side note. Im interested in scalability. The application will grow to become extremely large and I dont know at this point how relavent the company will be to the application other then just displaying maybe the company name or what not. but storing it in another table becomes another issue. <BR><BR>All I know is if I store it in another table and treat it as a seperate entity it shouldnt create duplicate records of the same company or it will be a problem. It seems I would have to develop a side application just to manage the company entities. Checking for dups... pulldowns with company names etc. It would be cool if I could pull it off though. I guess what Im wondering is.. What is the right and more efficient way to do it?

  2. #2
    Join Date
    Dec 1969

    Default RE: Database design question.

    I&#039;d have a separate, joined, companies table. definitely.<BR><BR>j

  3. #3
    Join Date
    Dec 1969

    Default RE: Seems familiar

    Pardon me if this is too simple. But I remember when I had questions like this as well and it was a basic understanding of a relational database that I was missing.<BR><BR>Whether or not to have 2 separate users tables depends on many variables, if you have 20k users and only 4 of them are ties to the company, then it would make more sense to have two users tables. If the balance is closer to 50/50 or even 70/30 company users to reg. users, then you could combine them into a single table.<BR><BR>As far as tracking the company name, you would want to have a separate table for that with a foreign Key that you could tie to the main users table.<BR><BR>You users table might look like this:<BR>---------------------------------------------------------<BR>[UserId(primaryKey)] [UserName] [CompanyId] [PhoneNumber]<BR><BR>And then you would have another table for the company info:<BR>---------------------------------------------------------<BR>[CompanyId(foreign key)] [CompanyName] [Location]<BR><BR>Now if you are only dealing with 1 company, that is... you want to specify simply whether or not a user is a member of *the* company, then you could just use a single users table with a Boolean field, say [IsEmployee] and then set that to true for everyone that&#039;s a member of the company.<BR><BR>I hope that helps, all this ASCII table representation is starting to confuse me, so I will stop. If I totally missed the point, sorry.. I tend to do that sometimes. Hopefully I didn&#039;t.<BR><BR>Good luck-<BR><BR>Steve<BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts