which one is the better normalization?

Question

I'm not good at normalization databases and I have scenario that get me confused.

We need a database for a storage software with some usual abilities like:

• storing customers and goods
• storing purchase invoice
• storing sales Invoice
• get us current amount of goods in stock.

well I have 2 options in my mind:

1. First Solution

We have 4 tables like this:

goods:

ID: PK; ->unique id for each of wares
Name  ; ->this is clear enough ;)

customers:

ID: PK;
Name; 

invoices:

ID: PK;
ID_Customer: FK;
Date;

invoices_items:

ID_Invoice: FK;
ID_Ware: FK;
Qty: quantity of ware that was bought or sold. for buying number is positive and selling number is negative

2. Second Solution

We have 3 tables like this:

goods and customers are like the first

invoices:

ID: its not PK;
ID_Customer: FK;
ID_goods: FK;
Date;
Qty

actually the difference between first one and second is in Invoices.

So my questions is clear:

1. Which one is better?
2. If there is third one that is better than my solutions please advice me.
3. Please tell me some ways that help me improve my power of normalization.

At last sorry for my bad English ;)

Answer 1

You should definitely go for the first... with both invoices and invoices_items. It is more normalized. The invoice date and other invoice data you may want to add in the future (number, status, date_delivered or other such stuff) should reside in its own table.

If you opt for the second solution you will have complex maintenance issues. If you want to change the invoice date, you will have to do so on all invoices_items rows. And you will never be sure you just have one single date on all rows. If data can go wrong... it will. To avoid this try to have all the data in the correct table, where it resides logically. Do not repeat it on multiple rows, just to save yourself the creation of one table.

Answer 2

Your first solution is better. In your second solution, you're effectively duplicating the date and customer for each item in your invoice, which is both more prone to error (What if the dates are different on items with the same ID?) and less storage-efficient.