[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Questions re database schema:street:address:urb:count
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Questions re database schema:street:address:urb:country |
Date: |
Wed, 1 Sep 2004 22:35:40 +0200 |
User-agent: |
Mutt/1.3.22.1i |
> See below for thread. Syan I agree wholeheartedly
But he is talking about primary and foreign keys ONLY. Not
simple fields. I agree it may be preferable to name primary
keys "pk_<table_name>" or "id_<table_name>" instead of just
"id" or "pk". OTOH, it is already perfectly clear what
"table_name.pk" is and IF we want to be explicit in naming why
not be explicit in a way that is already available *anyways* ?
Eg. I am again saying that we shouldn't reinvent namespaces,
and badly. OTOH again, I have had to resort to explicitly
name primary keys "pk_<table>" -- when I intended to inherit
from <table> and would thus end up with TWO "pk" or "id"
columns. In that case it was safer that way to make sure we
covered our bases in all cases of possible ambiguity. So
there :^)
> On Sat, 4 Sep 2004 07:03 am, sjtan wrote:
> > >>/ > 1) NOMENCLATURE in table generating queries:/
> > >>/ >/
> > >>/ > -Given that one will be doing various joins (and I'm not sure
> > >> if/ / > 8.0 supports outer), is there a reason not to name the ID's and
> > >> feids/ / > better:/
> > >>/ >/
> > >>/ > ===================================/
> > >>/ > CREATE TABLE public.country/
> > >>/ > (/
> > >>/ > id serial NOT NULL, (eg id_country serial NOT NULL)/
> > >>/ > code char(2) NOT NULL, (eg country_code..../
> > >>/ > name text NOT NULL, (country_name)/
> > >>/ > deprecated date, (country_deprecated)/
> > >>/ >/
> > >>/ > CREATE TABLE public.country/
> > >>/ > (/
> > >>/ > id_country serial NOT NULL,/
> > >>/ > country_code char(2) NOT NULL,/
> > >>/ > country_name text NOT NULL, /
> > >>/ > country_deprecated date,..... etc/
> > >>/ /
> > >>/ No, because in the join you have to explicitly name all duplicate
> > >> columns like/ / select country.id, urb.id from country, urb .../
> > >>/ /
> > >>/ The way yu would name it would notonly quickly exhaust the 32 byte
> > >> variable / / length in some cases and cause finger cramps in poor
> > >> programmers, it would / / also take a lot of reusability out of code
> > >> (like a code weeding out all / / "deprecated" rows of a table)/
> > >
> > >Agree.
> > >
> > >Karsten
> >
> > I always used to name every primary key field in any table , "id",
> > but the select.. natural join ..on .. mechanism suggests
> > it's better to have a unique id name for each entity, and to have
> > foreign keys in other tables identically named.
> >
> >
> >
> > _______________________________________________
> > Gnumed-devel mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/gnumed-devel
>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346