Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
SamC
White Water Yakist
3467 Posts |
 Posted - 2002-07-17 : 19:27:39
|
| My DB records for users have a growing list of requirements....Some users have 1 or more areas of responsability (e.g. admin, user, service)Some users have 1 or more "courses" which must be taken (e.g. course1, course2, ... courseN)Some users have 1 or more organizations to manage (e.g. dept1, dept2, ... deptN)Previously, the user record held the "single" values for all of the above, and the SQL querys were simple. The requirements seem to have outgrown the original design.The best solution I have come up with is to allocate a table for each of the above 3 "items", and put a record pointing to the user for each item owned.The SQL queries to retrieve the information will become more complex. Is there a simpler way to meet the "grow from 1 to N" requirement?SamC |
|
|
byrmol
Shed Building SQL Farmer
1591 Posts |
Posted - 2002-07-17 : 20:11:16
|
| SamC,Belive it or not, but that is the simpliest and correct way.Some may suggest having only a single table with a TYPE field, but IMHO that is an awful solution..(Troll)While the SQL will be more complex, they will be trivally so. You can hide this complexity by creating Views if you like.HTHDavidM"SQL-3 is an abomination.." |
 |
|
|
SamC
White Water Yakist
3467 Posts |
Posted - 2002-07-18 : 16:25:17
|
| I appreciate your confirming my approach before I dive into the implementation.Thanks,SamC |
|
|
|
MichaelP
Jedi Yak
2489 Posts |
Posted - 2002-07-18 : 17:48:52
|
I agree with byrmol. That's the way I currently do things, and it works fine. Users--->UserAreas<---Areas UserID AreaID MichaelP<Yoda>Use the Search page you must. Find the answer you will.Edited by - michaelp on 07/18/2002 17:49:51 |
|
|
|
|
|
|
|
|
Structure to handle Users owning multiple responsa