Re: paradigm sanity check needed [long] - Mailing list pgsql-general

From Matthew V." <
Subject Re: paradigm sanity check needed [long]
Date
Msg-id b1fm73$2bf2$1@news.hub.org
Whole thread Raw
In response to paradigm sanity check needed [long]  (will trillich <will@serensoft.com>)
Responses Re: paradigm sanity check needed [long]  (will trillich <will@serensoft.com>)
List pgsql-general
On Fri, 31 Jan 2003 22:30:45 -0600, will trillich wrote:

> i'd like to run our concept up the flagpole and see what kind of shots
> go plumb through it--
>
> you know how the standard recommendation is to have every field across
> the database with its own unique name? right?
>
> like school_student_certificate.school_student_certificate_year,
> long_enough_to_choke_a_horse.long_enough_to_choke_a_horse_thing...
>
> well, we're not doing that. not even close. all the literature says it's
> a good idea, but they don't say why. and we want to find out. :)
>
> here goes--
>
> EVERY table of ours has
>     *.id       serial primary key,
>     *.created  date default current_date, *.modified timestamp(0), *.by
>       references person(id),
>
> and when one table links to another (aside from the "edited by field
> above, that is) the name of the foreign key matches that of the table
> whose id we're after:
>
>     team.person      => person.id
>     team.org         => org.id
>     dates.date_types => date_types.id
>     loc.state        => state.id
>     loc.nation       => nation.id
>     project.org      => org.id
>     ...etc...
>
>
It's pretty much up to you and your organization.  What's most
maintainable for you?  Theory only goes so far--that's why we work so hard
to normalize relations only to struggle to find ways of de-normalizing to
views.  Programatically, logically, using your naming scheme is just that:
a naming scheme.  I personally like it, and I really *don't* like typing
60-character names (or even 30, with an alias, or whatever).

What you name your tables and columns should represent the data
accurately.  That way, when you hire a consultant, you don't have to pay
him for the time he (or she) takes figuring out an arcane and
non-representative naming scheme.  And your successors will bless your
name for intelligently naming you fields. :)

As far as the data is concerned, Postgresql doesn't care what you call it.
 I think as long as you avoid keywords you'll be alright.

Just my opinion, I could be wrong. ;)

--
Matthew Vanecek
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
********************************************************************************
For 93 million miles, there is nothing between the sun and my shadow except me.
I'm always getting in the way of something...

pgsql-general by date:

Previous
From: charette@writeme.com (Stephane Charette)
Date:
Subject: Cannot insert a duplicate key into unique index pg_calss_oid_index
Next
From: "Matthew V." <
Date:
Subject: Maximum length of a query