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 |
|
Billkamm
Posting Yak Master
124 Posts |
 Posted - 2006-02-24 : 11:45:20
|
| I have 5 tables in a productivity database: Groups, Task, Sub-Task, Market, and ProductA combination of any field in those 5 tables can be an entry into the productivity database. So like Group1, Task2, Sub-Task4, Market1, and Product2 could be an entry.Also, a lot of them don't need the lower categories such as sub-task, market, and product. Those can be left NULL.For each "entry" I need to specific other attributes that go along with each entry. I past productivity databases I combined all of my groups into a central table (called tblProcess in the last database)Then I would have:pkProcessId, Group, Task, Sub-Task, etc.. Attribute1, Attribute2, etc.. as the field names in tblProcess.However, I'm sure that this is a terrible design and I would like to improve upon in my new database. Does anyone have any suggestions or is this the best way of going about things? |
|
|
Non-conformer
Starting Member
14 Posts |
Posted - 2006-02-27 : 15:40:28
|
| Creating a table called tblProcesses (with fields for ID, Group, Task, etc, etc) is what you want. You only NEED separate tables for the other entities (Group, Task, etc)if your Processes table uses "codes". For example, you might use group code 1 to mean "Bicycles" and group code 2 to mean "Bananas", etc. Task code 1 might mean "Cook supper" and Task code 2 to mean "Plot a revolution", etc. Using codes thusly can make your Processes table tighter, and also allows you to institute foreign key constraints so your end users cannot input invalid data. Your call.Keep it simple.NC |
 |
|
|
|
|
|
|
|
Need help with designing a table structure