[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: v_basic_address.city now urb
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] re: v_basic_address.city now urb |
Date: |
Mon, 21 Feb 2005 10:01:41 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> I note some people are using pk_identity, pk_marital_status, etc., whereas
> before "fk_foreign_key" had been the convention. Karsten, can you confirm?
In tables I use fk_<something_but_mostly_table_name>, eg
fk_marital_status or fk_identity. These things are real
foreign key.
In views I have done
select
fk_marital_status as pk_marital_status
...
because a view is just an aggregation of fields, eg of several
primary keys and their associated data. Since the foreign keys
are coming from several tables it is impossible to say in a
view what is a foreign key and what isn't in most cases. Hence
all of them are pk_*.
So, most keys in business objects will be "pk_*" because most
business objects derive from views !
> >In cOrg, cPerson inherits from cOrg,
Which sounds non-intuitive. Please change cOrg to cParty.
> >What about v_basic_person.pk_identity vs org.id , how does that
> >integrate with org.id when
> >trying to refetch addresses ? I thought it was fairly simple just
> >overloading a method
> My preference was to keep org and v_basic_person consistent on the backend,
> but I can see this is a losing battle.
> I've put getId () back.
Tell me what to change to keep them in sync...
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346