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?

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.