Hi,
While doing the database design, we came across to a situation, where we need to finalize on composite keys and identity columns.
We have an entity, say A which has attributes A1, A2, A3, A4, A5 where A1, A2 and A3 together form a unique combination.
Another entity, say B has attributes like, B1, B2, A1, A2 and A3.
Another approach to the design could be in which we can have an identity in entity A, say Seq(primary key) and instead of having A1, A2 and A3 in entity B, we can just have Seq in entity B where Seq would be used in joins to fetch the records.
There could be one more approach to the design, in which entity A can have Seq(PK), A1, A2, A3, A4 and A5 and entity B can have Seq(FK), B1, B2, A1, A2 and A3. In this Seq would be used in joins for fetching the records.
Which one of the above three approaches is good for a DB2 database?
Thanks
Varsha
While doing the database design, we came across to a situation, where we need to finalize on composite keys and identity columns.
We have an entity, say A which has attributes A1, A2, A3, A4, A5 where A1, A2 and A3 together form a unique combination.
Another entity, say B has attributes like, B1, B2, A1, A2 and A3.
Another approach to the design could be in which we can have an identity in entity A, say Seq(primary key) and instead of having A1, A2 and A3 in entity B, we can just have Seq in entity B where Seq would be used in joins to fetch the records.
There could be one more approach to the design, in which entity A can have Seq(PK), A1, A2, A3, A4 and A5 and entity B can have Seq(FK), B1, B2, A1, A2 and A3. In this Seq would be used in joins for fetching the records.
Which one of the above three approaches is good for a DB2 database?
Thanks
Varsha