gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]