Re: The MySQL/PHP pair

Ken:

"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:aag962-efe.ln1_at_pluto.downsfam.net...

[snipped]

> Bill, I'm not sure we're using the same terms in the same ways.

Right. When have we ever? :-)

> What you call "auditing" I call "automation" but they do the same thing,
> generate additional columns out of existing columns, and also update other
> tables such as order_header based on order_detail.

Sounds good. To create audit information I usually tally order_detail as it's created and update the order_header detail total. I'll use it later. :-)

> But I don't believe this is 1NF we are violating, but rather 3NF.
Strictly
> speaking, the following is in 3NF (we'll assume unique on order# + item,
> which works in an example):
>
> Order # Item Qty
> ======= ====== ===
> 123 WIDGET 5
> 123 BWHIP 6
>
> As soon as I bring in price, I have technically violated 3NF because it is
> key-dependent upon Item, not Order + Item. This is common practice, and
> we'll assume that our table is now:
>
> Order # Item Qty Price
> ======= ====== === =====
> 123 WIDGET 5 5.00
> 123 BWHIP 6 7.00
>
> As a further Abomination to the priests of Normalization, I will add the
> column Extended = price * qty, which is a further violation of 3NF:
>
> Order # Item Qty Price Extended
> ======= ====== === ===== ========
> 123 WIDGET 5 5.00 30.00
> 123 BWHIP 6 7.00 42.00
>
> So my original question was about 1NF. You stated that 1NF will not
support
> auditable systems, but it seems to me that we will violate 3NF, not 1NF.
> Did I mistake your meaning?

I really don't want to quibble about this 1NF stuff. You've noted the problems. They exist. We, as developers, deal with them every day. I'll bet you do too. Normalization is a rule that needs to be broken for a variety of reasons. So many reasons, in fact, that one questions the rule. :-)

Thanks,

Bill Received on Thu Nov 11 2004 - 07:28:15 CET