ScottPletcher (7/9/2012)

---

SQLKnowItAll (7/9/2012)

---

ScottPletcher (7/9/2012)

---

SQLKnowItAll (7/9/2012)

---

ScottPletcher (7/9/2012)

I know why the date was left out of the Sales table -- it can be derived.

What am I missing... How can it be derived?

Join back to the Account table using AccountId.

Maybe I am missing something... Or just lack of information... However, I believe that rows are inserted into the accountsales table regularly, while only 1 row for each account is inserted into the accounts table. So I could have a createddate for account 10000 today, and then rows added to accountsales with this account today, 3 days from now, 3 years from now... So how do you know when the actual sale happened versus when the account was created. Mind you, I am thinking that these tables are representative of a Customer and Orders table.

Maybe it's just me. I took Account to be more of a header and Sales the details for a sale.

Based on the names, you're probably right though.

Even then, I would expect there to be a "order header" table that stores the date/time of the sale. And that the datetime of any individual item on that order could be derived from the header table's sale date.

Typically, I would cluster order header and detail tables by OrderId.

IF, though, it has been decided to cluster the "header" table by date, I would consider (not necessary do, but consider) denormalizing and putting the date in the sales table to facilitate joins.