Message-Id: <m10Louh-0000buC@druid.net>
Subject: Re: [INTERFACES] [off-topic] Database normalization, can't be don e!
In-Reply-To: <93C04F1F5173D211A27900105AA8FCFC14527E@lambic.prevuenet.com>
	from Michael Davis at "Mar 13, 1999 02:05:25 am"
To: michael.davis@prevuenet.com (Michael Davis)
Date: Sat, 13 Mar 1999 08:57:15 -0500 (EST)
From: "D'Arcy" "J.M." Cain <darcy@druid.net>
Cc: pgsql-interfaces@postgreSQL.org
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Thus spake Michael Davis
> I copy the unit cost and unit price into the invoice.  This makes sure the
> invoice does not change even though the inventory could change.  May not be
> normalized but this is necessary.  The invoice still references the

In fact, it is normalized.  You just have to realize that things that
look similar and have the same name could still be different attributes.
In this case, you have two distinct attributes, the current, theoretical
price if you were to sell something and the actual price charged to a
client.  Of course, these two are related in a conversational sense and
certainly one is derived from the other but item price is only one of
the components of invoice price.  Another component (there could be
more such as client code, etc.) would be time.

In any case, ultimately your database should be designed to get the job
done, not to be the basis of a thesis on database design.  I'm not
saying that you shouldn't worry about normalizing your database but
like many things it is important to understand the theory so that you know
when to break the rules.  As long as you know what you are doing and it
is a conscious decision, a database schema could be 98% correct and
still be a good design.  The test is, is it the best way to do the job.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.