Re: why not a one table database ?

one rule of thumb in normalization is to make sure that if you delete for example a car from the db that ALL other information is kept intact: ie. delete the blue car for customer A because be bought a new yellow car......in a single table db deleting the BLUE car for customer A may essentially delete past customer history, amount of visits from that customer or from the BLUE car. If the manager wanted to find out who is his best customer or who spent the most, or suggest to a customer that his/her car would well be worth replacing because of mechanical failures because the manager wants to sell him/her a car from his lot......All history information on car BLUE and as relative to customer A is gone

Summary: Delete the customer, the car the history or financial information in relation.......but keep everything else......

Stephane Gosselin wrote:

> Hi. I need a question answered, if anyone can clue me in....
> a friend of mine just completed a project wich consists of slapping
> together a simple d-b for a local garage. He did it in access, & it
> basically is made up of ONE table, in wich all customer information is
> supplied,(Name,Tel, Address, & a field for the model of the car.
> The customer wants to be able to find his customers just by typing in
> a phone number..... wich in itself is simple. Never having done a d-b
> on a commercial level myself, I tried to ' convince ' my friend that
> he needed two, maybe three tables to prevent redundancy in his data
> For example, if you have 2 customers at same adress..... or 1
> customer with 2 cars ? What defines the number of tables used in a
> small project like this ? Any reading material would be appreciated.
>
> Thanks .
>
> Stephane Gosselin
> stef_at_cfusions.com
>
>
>
Received on Wed Aug 09 2000 - 00:00:00 CEST