Re: Sales db design...

Me schrieb:
> Hi all,
>
> I have a simple question, really.
> I'm trying to build a database to handle sales. I've been looking around
> at examples, both on the net and example db's such as "Northwind" that
> MS puts out as an example, and I see that it's common practice to handle
> line items for *all* invoices in *one* table and then retrieve line
> items for each invoice by the invoice number column that's included in
> the line item table. With numerous line items on each invoice this will
> obviously generate an absolutely *massive* table eventually, assuming
> that the company in question does a high sales volume. Seems counter
> intuitive to me, but I can't think of a better way to do it. Is this
> really the best way to handle this? Any other suggestions?
A few billions of rows aren't supposed to be a problem for a real database.

What's often done (if the underlaying database permits it) is to partition the table so that you have a small one with the open invoices and a large partition for archival purposes. Those partitions are then placed on different discs.
That way you can do fast oltp on one partition, and the warehousing and reports on both. Or rather, that's what the database does. You just run queries.

Lots of Greetings!
Volker Received on Thu Feb 23 2006 - 16:29:29 CET