[ic] Normalized database for the Foundation demo.

[* *]

Hi Mike,

>In this case there is a very good reason.
>
>What if the customer changes their address after the order is shipped?
>You will have no record as to where the order went -- maybe even where
>it should go.
>
>With product descriptions and prices this is even more important.

I understand that, but using normalized tables wouldn't prevent us from 
maintainng this kind of functional requirements. We would only have to use 
other tables to track history.
But my point is that the DB is NOT normalized and that's what I found 
difficult to understand. My university 'Data Structure' teacher sounded so 
convincing when talking about normalization :°).
Interchange/foundation has been around for a while and users/developers 
seems to be fine with it. So I'll dig deeper in it and see exactly what 
potential problem I might have with it not being normalized and come back to 
this mailing-list.

>To work with 3NF, we would have to have
>processing filters for all sorts of things, and would probably have to
>use foreign key constraints not available for MySQL (or design our own
>importers that implemented those).

MySQL does support foreign key since InnoDB, and (explicit support of) 
foreign keys are not a necessity to join tables.

>It would also be possible to build some pseudo-constraints which
>did some updating of transaction/orderline info when a customer
>record changed.

We could, but this sounds like moving database layer constraints to the 
business logic. I wonder what my 'Data Structure' teacher would say about 
that :°) .

>That being said, it wouldn't be too difficult to produce a "foundation-3NF"
>template which implemented a normal-form database structure if you wanted
>to do that.

Yes, I would like to do that. Any idea of where I should start from ?

Cheers Mike,
Dominique.