Josh, sad,
> create table diagnosis (
> pk serial primary key,
> fk_patient integer
> not null
> references patient(pk)
> on update cascade
> on delete cascade,
> narrative text
> not null,
> unique(fk_patient, narrative)
> );
>
> This was o
On Friday 23 July 2004 12:27 pm, Karsten Hilbert wrote:
> BTW, our full schema is here:
>
> http://www.hherb.com/gnumed/schema/
i was looking at your schema. i'm not a database pro, but in master tables i
see you have made the serial id as the primary key. i do it this way:
id serial uniqu
On Jul 23, 2004, at 4:57 PM, Kenneth Gonsalves wrote:
On Friday 23 July 2004 12:27 pm, Karsten Hilbert wrote:
BTW, our full schema is here:
http://www.hherb.com/gnumed/schema/
i was looking at your schema. i'm not a database pro, but in master
tables i
see you have made the serial id as the primar
On Friday 23 July 2004 03:29 pm, Michael Glaesemann wrote:
>
> You appear to be misunderstanding the purpose of a primary key. A
> primary key is used to ensure there is a way to identify each row
> uniquely. It is quite independent of which columns you may or may not
> want to search on. If name
On Jul 23, 2004, at 6:00 PM, Kenneth Gonsalves wrote:
On Friday 23 July 2004 03:29 pm, Michael Glaesemann wrote:
You appear to be misunderstanding the purpose of a primary key. A
primary key is used to ensure there is a way to identify each row
uniquely. It is quite independent of which columns you
On Friday 23 July 2004 04:47 pm, Michael Glaesemann wrote:
> > id serial unique
> > namevarchar(25) not null
> > primary key is name - after all, you are going to search this on name
> > arent
> > you? or is there some advantage in doing it your way?
>
> Also, your explanation "after all,
Regarding natural or surrogate keys...
It is often possible that a table definition does not depict
reality, meaning that the specification given at table design
phase was wrong, (or was later proved wrong).
I had a table "parts" like
\d parts
Table "public.
Am Freitag, 23. Juli 2004 12:02 schrieb Kenneth Gonsalves:
> ok, i'll rephrase the whole thing:
>
> i have a master table with two fields:
> id serial unique
> name varchar not null (and will be unique)
>
> i always make 'name' the primary key, and since it is the primary key, i
> dont explicitly s
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> You appear to be misunderstanding the purpose of a primary key. A
> primary key is used to ensure there is a way to identify each row
> uniquely. It is quite independent of which columns you may or may not
> want to search on. If name is not going
Achilleus,
> In other words, with surrogate keys, you eliminate the chance
> that your original design was flawed due to lack of important
> initial knowledge.
Well, you don't *eliminate* it, but you do decrease it.
I'd say, yes, this is an important 4th reason:
4) Your spec may be incorr
Karsten,
> Because there is no information to be had on this fact. The
> patient IS afflicted by such or she is not. There is no why.
I begin to see why I spent $2000 this spring to have a doctor tell me what I
*didn't* have ...
> http://www.hherb.com/gnumed/schema/
>
> Lot's of it isn't in t
11 matches
Mail list logo
