Structuring a Daily Sales Database - mysql

Question

I would like to build a very basic daily sales report. I'm am trying to decide how to structure the database to best accomplish this. Here is a use case for it:
On Jan 5, 2011, Provider A makes $500 total off of its products
On Jan 5 2011, Provider A makes $200 total off of its products
On Jan 6, 2011, Provider B makes $450 total off of its products
On Jan 6, Provider B makes $75 total off of its products
The current structure I have is:
PROVIDER table
pk
provider
PRODUCT table
provider (FK)
product
start_date (sales)
end_date
The start_date and end_date are when sales on the product may occur. It is only used for reference, and does not really affect anything else.
SALES table
product (FK)
sales
How to store date ??
sales would be the daily proceed ($) for sales from that product.
I'm not quite sure how to store the sales. Sales would only be calculated as a daily sum for each product. What would be the best way to structure the SALES table? Thank you.

Answer 1

Product Table:
This table should be 'transitory' in nature. Meaning that it is flexible to change over time.
In 2011 you may sell Product A for $15.99, but in 2012 you want to sell the same product for $16.99, so you want your table to be flexible enough to this type of change.
Although there is flexibility with the data stored within this table, care must be taken if you ever delete a product. If you delete a product, it will either orphan any matching sales transactions in the sales table, or delete them (depending upon FK behavior).
Sales Table:
This table should be 'transactional' in nature. Meaning that a row represents a product linked to a sale, frozen in time.
If buyer A purchased Product A for $15.99 in 2011, you want to record this transaction as is, nothing changes with the data at any point in time, it reflects a transaction.
If buyer B purchased the same Product A but for $19.99 in 2012, you want to record this as a separate transaction. Sure it is the same product, but this row represents a new transaction.
With the aforementioned setup, you can change prices as you see fit in the product table, but it won't affect already occurred sales recorded in the sales_transaction table.
Pseudo schema:
product:
id int(11) unsigned not null auto_increment
name varchar(255)
price decimal(14.2)
primary key (id)
unique key (name)
sales_transaction:
id int(11) unsigned not null auto_increment
product_id int(11) unsigned not null
provider_id int(11) unsigned not null
price decimal(14.2)
created_at datetime default '0000-00-00 00:00:00'
foreign key (product_id) references product('id') on delete cascade
foreign key (provider_id) references provider('id') on delete cascade
provider:
id int(11) unsigned not null
name varchar(255) not null
primary key (id)
unique key (name)
Now, you can run queries to get summations of any product for any date for any provider, as you requested in your question.
Sample Query:
# On Jan 5, 2011, Provider A makes $500 total off of its products
SELECT prov.*, SUM(sales.price)
FROM
provider AS prov
INNER JOIN
sales_transaction AS sales on sales.provider_id = prov.id
WHERE
provider.name = 'Provider A'
AND
sales.created_at BETWEEN '2012-01-05 00:00:00' AND '2012-01-05 23:59:59'
GROUP BY
prov.id
The schema provided is skeletal in nature, so feel free to add columns as your business requirements dictate, but it should get you going in the right direction.
Also, a final piece of advice, I would recommend storing your datetimes in UTC. If you opt to store in local timezone you will run into any number of headaches if you do any sales requiring conversion from your local timezone.

Answer 2

Why not a date field in the sales table? That would make each record the sales total for a certain product, on a certain date.