>And, I had always heard that lazy people make great programmers. :)

This fits with the other thread yesterday... lazy is the keyword, and it does make sense: if we weren't lazy, we wouldnt't go through so much trouble to get these machines do our job, right?

>Actually I was extapolating (Is that the right word?) from a statement you made earlier that you didn't see how I found a simple 3 table join complicated.
>
>Take the 3 table join you were referring to and add two more table joins and now you have 5.

I don't know whether SQL server (or other DB servers) behaves the same as Fox's SQL, but in the latter case my rule of thumb is to go through few shorter selects and then join. In this case:
- select invoice headers into cursor1
- select customers, cities, states (join here) for customer IDs in cursor1 into cursor2
- join now from these cursors.
Basically, if I have one huge table to select from, I do a single select from it, no joins. That's fast and easy on the database engine, and the resulting cursor is short (or narrow) enough to be the base for further joins.

>But, I take it from this that your preference would be to store the id.

That's the measure of redundance you may want to introduce, provided the data there isn't prone to changes. I've usually stored the invoice date in both invoice header and line items - because it never changed, and I had a bunch of reports which pulled from line items only, based on this date.

Also, I've had invoices without line items - which were corrections of previous invoices, or just lump sum charges for unspecified extras. They also had no orders - and in these cases you'd have no place to put the customer ID if it wasn't in the invoice header. Actually, back home very few things had an order at all - we usually sent a pro-forma invoice, and if it was aggreed upon (or even paid), that served as an order, but most of the time there were long term deals or just phone agreements, which were billed periodically or ad-hoc, therefore no orders most of the time.

>I'm having difficulty coming up with a good example. But let's say work orders had a customer Id and in the Invoice Header you stored the Work order Id. To get at the customer information from the Invoice Header table you would have to join to the Work Order table and then to the Customer table.
>
>So by adding a Customer Id, you would simplify the join to the Customer table.

Aside from reasons stated above, the orders table is something you need until the invoice is sent, but then for general reporting do you really need them? IMO, the invoice is what counts as really done (orders may be cancelled, right?), so once you get into reporting I'm not sure you really need the orders. But then, I'm not really too well acquainted with the business logic here; several things were different back home and quite a few of my assumptions may be wrong.
Still, a customer ID on an invoice should never change. Even if it's wrong, you'd cancel the invoice and the order and create a new one. Therefore, a copy of customer ID will not introduce maintenance hassle. Equally, storing the state with the ZIP should be OK - I haven't heard of too many cities travelling between states recently.