Question

So I’m writing an application in C# using SQLITE that will keep track of my companies sales data. We currently track sales data 12 months (including the current one) out and track it each day. I’m planning to have the ability to compare our sales data between two points (or more) in time as well, and this is the database I’ve designed so far. It’s comprised of two tables:

salesIndex is a table with two columns, a unique id and a text representing a timestamp. This is sort of a master table to list all the times we tracked our sales data.

salesData is a table with 7 columns, the first being the id from the previous table, the second being the sales date and the next 5 are integers describing what kind of sales (ie the quantity, etc).

The concern I have is that if we do this each day for every day it’s ~133k tables a year, and we’d store data for 3 years so ~400k rows and I’d imagine that would be somewhat slow to retrieve data from. Is there a better way to design a database for this? I was thinking perhaps I should create a table each day we track our sales and that way if we wanted to look up sales for a number of days we would just query each table rather than one huge one? Any help is appreciated 🙂

Answer 1

Please don’t create that many tables. You’ll not just have maintenance difficulties, you’ll also hurt your performance.

Simply have a single sales table with properly identified rows (which in your case probably means adding date to the primary key). Assuming you used indexes correctly, performance will be good even with 400 million rows, let alone 400 thousand rows.

A typical index is implemented as a B-Tree, whose height (and consequently the speed) depends logarithmically on the number of rows. In practice, this means a properly designed index will work almost instantly even on huge amount of data.