Re: [PHP] Re: Where to start!

[email protected] ("Tony Marston")
Newsgroups php.general
Message-ID <[email protected]>
"Jason Pruim" <[email protected]> wrote in message 
news:[email protected]...
>
> On May 5, 2008, at 6:21 AM, Tony Marston wrote:
>
>>
>>
>>
>> Anyone who doesn't know how to reach 3NF shouldn't be designing 
>> databases.
>
> Just out of curiosity... How many Records do you need to have in a 
> database before you'll start seeing a performance boost from doing  that? 
> I have written a few database apps that work quite well with no  formal 
> training in PHP or Database design.. Don't want to start any  wars here... 
> I'm just curious :)

It is not the number of records which is the deciding factor - it is:
a) is the data  want in the right place (for easy access)?
b) can it be upated easily?

For example, many years ago I had to take over maintenance of a database 
which was designed b someone who was not technically competent. There were 2 
paticular tables, "order_header" and "order_lines". The order had a status 
value, as did each of the order lines. So where did this twit choose to 
store the order status? - you've guessed it, on the order_line record. His 
rationale was that when traversing the order_line recods it was easier to 
have the order_status on that record instead of having to perform a separate 
read of the order_header record. The flaw in this argument was that when you 
wanted to change the status of an order you had to update every order_line 
record. Problems arose later when a software bug (introduced by him, BTW) 
left different values for order_status across different order_lines.

The rules of normalisation dictate that order_status goes on the 
order_header record, and is not dupliacted across several order_line 
records.

-- 
Tony Marston
http://www.tonymarston.net
http://www.radicore.org


> --
>
> Jason Pruim
> Raoset Inc.
> Technology Manager
> MQC Specialist
> 3251 132nd ave
> Holland, MI, 49424-9337
> www.raoset.com
> [email protected]
>
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.