Sales order item details storage, which way to go?

I'm working on a type of inventory management application using the following mixture or technologies: MySql, C#, WPF, ADO.Net EntityFramework 4.

I'm a little confused as to how I should store the details on the sales/purchase invoices in the database.

This is how I had it before... I stored the details in a LongText field as an XML string.

+---------------------------------------------------+
| SalesInvoices                                     |
+---------------------------------------------------+
| int InvoiceID: primary key, auto-incretement      |
| int OrderID                                       |
| int CustomerID                                    |
| int CreatedByEmployeeID                           |
| DateTime Date                                     |
| DateTime? ShippingDate                            |
| LongText ItemsData (details, stored as XML)       |
| LongText TransactionData (details, stored as XML) |
| Double Subtotal                                   |
| Double Tax                                        |
| Double Freight                                    |
| Double FreightTax                                 |
| Double Total                                      |
+---------------------------------------------------+

However, I looked around on the web and most of the examples I've seen have a separate table SalesInvoiceDetails. So I'm wondering, is there something wrong with my approach, should I go through the trouble of switching over to the approach.

My Requirements: The search through the SalesInvoice table should be really fast. I do not need to search through the details of the invoice unless the user actually opens up an invoice, so It's okay if the user has to wait a second or two over here.

The reason I chose my approach the first time was because I thought millions of details in one table will eventually make it really slow to open and I would have to worry about deleting and updating rows if a user decides to go back to change something. And I thought it would be a bit of a hassle to have sub items for detail lines and storing them as rows and keeping track of the parent/children relationship and etc.

So yea, I'm wondering is there any good reaso开发者_高级运维n why I should abandon my approach and make another table for the details.

Why you think using separate table would be slow? I think you need to read(If you haven't yet) about Database normalization, indexes and so on to get good performance. To update detail now you need to transfer and insert whole blob instead of, for example one price field.

Also I found nice article here. I realy liked what author wrote(good point to abandon your approach):

This isn't a bad approach, since it records every purchase made by every customer. But what if you started to ask complicated questions, such as:

How many 3" Red Freens did Freens R Us order in 2002?

What are total sales of 56" Blue Freens in the state of Texas?

What items were sold on July 14, 2003?

That's my opinion :)