Normalization (1 Viewer)

[casey]

Hello all,

It's been a while since data normalization class and I'm looking for some advice.

I have an Invoicing/Ordering DB for Products, while doing "data normalization", we figured that redundant data would occur between Invoice Detail and Order Detail so we combined the two tables into the Invoice Detail table. The table contains the following fields:

InvoiceID, PONumber, ProductID, Qty, Price, Cost, Priority, OrderQueue(Y/N), Ordered(Y/N), OrderQty

This works nicely for the application's purposes, but I think that one could dispute its design according to "proper" normalization rules.

Does anyone see a problem w/ doing this? Should I split these tables into separate tables?

Any ideas will be appreciated greatly.

 

[casey]

I suppose that my thread was not exactly concise...

My question concerns the functionality of normalization. Is the idea of normalization basically to use minimal table space and limited redundancy predicated on the fact that a relational database can join multiple tables when needed to allow data located in two or more tables to be viewed/edited/updated as though it were stored in one table?

If so, then further normalization will never lose practicality as long as the users are able to join multiple data stores.

Is that right?

I would appreciate any enlightenment.

 

[Pat Hartman]

The purpose of normalization is to ensure data integrity not to reduce storage requirements. Non-key data that is duplicated is subject to update anomolies. That is data that is updated in one table but not in the other(s) which causes it to get out of sync.

I think that your choice to use the same detail table to support both orders and invoices is correct. The details of an order don't change when you create an invoice for it.

 

[casey]

This is a rather costly issue for me. As many times I end up chasing my tail going back and forth between different designs wieghing practicality vs. functionality. I appreciate your input.

Thanks for the clarification.