Re: paradigm sanity check needed [long]

From: "Matthew V(dot)" < <deusmech(at)yahoo(dot)com>>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: paradigm sanity check needed [long]
Date: 2003-02-01 05:33:35
Message-ID: b1fm73$2bf2$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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...

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Keith Keller 2003-02-01 07:05:24 Re: [NOVICE] Perl - Postgres
Previous Message Curt Sampson 2003-02-01 05:07:00 Re: One large v. many small