Skip site navigation (1) Skip section navigation (2)

Re: problem with parent/child table and FKs

From: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
To: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: problem with parent/child table and FKs
Date: 2011-04-21 17:15:38
Message-ID: F0242E63-9F8A-4C5C-94A5-1D3651E4E7A7@solfertje.student.utwente.nl (view raw or flat)
Thread:
Lists: pgsql-general
On 18 Apr 2011, at 15:53, Karsten Hilbert wrote:

> What is the suggested approach for this situation ? (there
> will be more tables like "icd10" holding other coding
> systems of fairly diverse nature but all of them sharing
> .code and .term: LOINC, ATC, ICPC-2, ICD-9, ...).

I think your best bet is to not rely on inheritance here. If you instead reference code_root from icd10 using (code, term), you end up with the same results, while you then only need to reference code_root from your lnk_codes2epi table.

> begin;
> 
> create table code_root (
> 	pk_code_root serial primary key,
> 	code text not null,
> 	term text not null
> );
> 
> create table icd10 (
> 	pk serial primary key,
> 	version text not null
> ) inherits (code_root);

So this would become:

create table code_root (
	pk_code_root serial primary key,
	code text not null,
	term text not null,
	UNIQUE (code, term)
);

create table icd10 (
	pk serial primary key,
	code text not null,
	term text not null,
	version text not null,
	FOREIGN KEY (code, term) REFERENCES code_root (code, term)
);

This does rely on the combination of (code, term) being unique in code_root. If it's not, you would need an extra table with just every unique combination of (code, term) that both code_root and icd10 would reference.

BTW, do you really need those artificial PK's? If not, you may well be better off dropping them. That way (code, term) could be your PK instead. I don't know enough about your data to make more than a guess though, I just get itchy when I see such designs ;)


Alban Hertroys

--
If you can't see the forest for the trees,
cut the trees and you'll see there is no forest.


!DSPAM:737,4db0665111731275120228!



In response to

Responses

pgsql-general by date

Next:From: hubert depesz lubaczewskiDate: 2011-04-21 17:58:54
Subject: Re: How to realize ROW_NUMBER() in 8.3?
Previous:From: raghu ramDate: 2011-04-21 16:59:20
Subject: Re: How to realize ROW_NUMBER() in 8.3?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group