Re: [OT] Normalization

From: Tony Marston (tony_at_NOSPAM.demon.co.uk)
Date: 01/22/04 

Date: Thu, 22 Jan 2004 11:36:11 -0000

"Dag Sunde" <dag.nope@orion.no.way> wrote in message
news:3fNPb.31087$BD3.6856540@juliett.dax.net...
> "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message
> news:bumnv9$97l$1$830fa7b3@news.demon.co.uk...
> >
> > "Dag Sunde" <dag.nope@orion.no.way> wrote in message
> > news:iOAPb.31053$BD3.6835845@juliett.dax.net...
> > >
> > > "Tony Marston" <tony@NOSPAM.demon.co.uk> wrote in message
> > > news:bumgb3$car$1$8302bc10@news.demon.co.uk...
> > > >
>
> <snipped />
>
> > > > I have personally dealt with all the circumstances identified in
that
> > > paper
> > > > so I speak from experience. Everybody else is simply repeating what
> they
> > > > have been told.
> > > >
> > >
> > > That last paragraph is probably the most arrogant I've read in the
last
> > > 12 months!
> > >
> > > :-)
> > >
> > > What you are saying is that since you have experienced a set of
> problems,
> > > and choosen the solution you prefer to each one, that is the *Correct*
> > > way of solving that particular set of problems
> >
> > I am simply disagreeing with those who say that you *must* use a
technical
> > primary keys on every database table.
> >
> > > Have the thought occured to you that there is other people out here
with
> > > the same or higher level of experience that you?
> >
> > There may be, but is doesn't stop them from producing crap solutions.
> >
> > > And that those people have found a different, but just as good, or
> better
> > > way of solving a particular DB-Problem?
> >
> > A problem can be solved in many ways, but saying that technical primary
> keys
> > are a universal solution in every possible situation is just plain
> > ridiculous.
> >
> > > I mean, Honestly... "Everybody else is simply repeating what they have
> > > been told."... That is ridiculous!
> >
> > Not in my book it isn't. Every time I meet someone who says "you must
use
> a
> > technical key on every database table" I ask them "Why?" Their answer is
> > always "Because that is what I have been taught." When I take them
through
> > the examples contained in my article they reply "But I've never actually
> > dealt with that situation."
> >
> > Well, I HAVE dealt with all those situations, both with using other
> people's
> > designs which included the "obligatory" technical key, and using my own
> > designs which removed the totally useless technical key. The reason I
> > changed the database design for those situations was to provide a better
> > solution for the user and an easier solution for the developer to
> implement.
> >
> > I will match my 25+ years of design and development experience against
> your
> > 25+ minutes of reading some theoretical clap-trap any day of the week.
>
> Pleas note that I Agree with most of the arguments you put forth in you
> paper.
> My 15+ years of design and development experience have led me the to much
of
> the same conclusions as you.
>
> Actually most of it, except your fear of resource consumption concerning
> indexes...

I started designing databases over 20 years ago when hardware costs were
VERY expensive compared with programmers, so we had to account for every
byte on every record. Each index requires extra disk space plus processor
resources to maintain it, so if an index is not actually necessary all you
are doing is wasting resources.

> It was the general "everybody else are idiots" attitude i reacted to.
>

I did not say "everybody else is an idiot". What I actually said was "I have
personally dealt with all the circumstances identified in that paper so I
speak from experience. Everybody else is simply repeating what they have
been told."

Those designer/developers who have actually encountered the scenarios
outlined in my paper and tried solutions with and without technical keys
will be in a better position to judge the relevant merits. Those people who
do not have this experience are simply echoing what they have been taught,
not what they have learnt. There is a big difference.

Tony Marston
http://www.tonymarston.net/

Relevant Pages

  • Re: design question
    ... Are you sure you don't mean "primary keys made up by composing several ... The second stage was logical database design, ... SQL modeling and relational modeling that I've since seen in this newsgroup. ...
    (comp.databases.theory)
  • Re: Primary, Foreign Key questions
    ... I am using Visual Data Manager to create and/or modify my database. ... > ¤ Is it correct that Unique and Required be checked in all 3 tables for their respective Primary ... > Primary keys are always unique. ...
    (microsoft.public.vb.database)
  • Re: Relation Schemata vs. Relation Variables
    ... Identity beyond that provided by the identifying keys is a nonsense. ... design a system whether a key that appears to be very stable will remain ... I was called in to fix a problem at a company where management ... During that period the database became corrupt because it allowed changes ...
    (comp.databases.theory)
  • Re: WHY doesnt C know anything about directories?
    ... We should put everything into a database (including making the file ... How many keys do these proposed database filing systems require? ... The proposed navigation calls already support UP, ACROSS, and DOWN ... first retrieve all the primary keys, and then for one primary key, ...
    (comp.lang.c)
  • RE: Tables Question
    ... You need to design your tables and database... ... Determine the relationship between the tables and add foreign keys as ... >> CommittedBus (filled in as the year progresses) ...
    (microsoft.public.access.tablesdbdesign)