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.

 All Forums
 General SQL Server Forums
 Database Design and Application Architecture
 Better way to design this table?

Author  Topic 

dhw
Constraint Violating Yak Guru

332 Posts

Posted - 2009-06-26 : 15:04:08
Hi all

We have a table that contains problems and need a way to track the things that resolve this problem.


Table of Problems
- ProbID is the primary key

Tables of things can solve a problem
- CustomerSoln (CustomerSolnID)
- HardwareSoln (HardwareSolnID)
- etc.

current plan is to have a table, Resolution (let's say) with"

pkID
ProbID (Fkey back to Problem table)
ResolverID (ID of the thing that solved)
ResolverType (reference to the table - notes, soln, etc)

this table design seems to allow for some flexibility and we don't have to create 4 or 5 or 10 different Problem-to-Resolution JOIN type tables. However, it is probably not optimized because of the lack of a foreign key relationship?

Anyway, I am just wondering what others think of this and if there might be a different (better?) way of handling this?

Thanks
- will

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-06-26 : 15:11:10
i would have also done similar way except for creating a seperate table for resolvertypes with ResolverTypeID as PK and including only it with a FK relationship in Resolution.
Go to Top of Page

dhw
Constraint Violating Yak Guru

332 Posts

Posted - 2009-06-26 : 17:59:20
Interesting. Hmmmm, I didn't think about that. I like that idea as well. Thanks!
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-06-27 : 01:15:45
quote:
Originally posted by dhw

Interesting. Hmmmm, I didn't think about that. I like that idea as well. Thanks!


the advantage is whenever you need to modify any data in type you just need to update only a single record in type table rather then finding and updating all records in Resolution which has this type.
Also you will be able to store any ResolverType values even if it currently does not have a resolution record.
Go to Top of Page

dhw
Constraint Violating Yak Guru

332 Posts

Posted - 2009-06-28 : 03:43:52
quote:
Originally posted by visakh16
the advantage is whenever you need to modify any data in type you just need to update only a single record in type table rather then finding and updating all records in Resolution which has this type.
Also you will be able to store any ResolverType values even if it currently does not have a resolution record.



Excellent points. Thanks again.
Go to Top of Page

visakh16
Very Important crosS Applying yaK Herder

52326 Posts

Posted - 2009-06-28 : 12:58:17
welcome
Go to Top of Page
   

- Advertisement -