Cindy-

I appreciate your input.

These are problems that I'm always dealing and yet I've seen a really good data base design, Normalized to 3rd Normal Form. Everything I've seen either goes overboard with normalization, along with poor design or they flatten everything out, which can be a nightmare in and of itself.

>Dan,
>
>Yes, you'd have to go through the InvoiceHeader to get the customer's details, but you'd probably want that information there anyways.
>
>Again, it's much simpler to have normalized data and do a little extra typing each time. You'll never have to do cleanup operations when your tables are out of synch and it will be easier to add new features into your database later on.
>
>However, if you had a data warehouse with huge amounts of data loaded in batches on a monthly basis, and you often wanted customers and Invoices without the work order stuff, then I'd add the customer ID to the Invoice Header table.
>
>
>
>>Another point. Some people for reporting purposes like to store IDs into tables to simplify joins at a later time, even though the IDs don't really belong.
>>
>>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.