Re: paradigm sanity check needed [long]
От | Matthew V." < |
---|---|
Тема | Re: paradigm sanity check needed [long] |
Дата | |
Msg-id | b1fm73$2bf2$1@news.hub.org обсуждение исходный текст |
Ответ на | paradigm sanity check needed [long] (will trillich <will@serensoft.com>) |
Ответы |
Re: paradigm sanity check needed [long]
|
Список | 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 по дате отправления: