title: Store time ranges - best practice
body: <p>I have an Azure account on which I can use one SQL database and the storage services - tables, blobs, queue - (nothing else due to budget constraints and the solution must be as cheap as possible; I am inclined to use the storage services as much as possible). </p>
  
  <p>Our application generates some events and we want to be able to see how many events per day were generated and compute some averages.</p>
  
  <p>I am looking for solution to store the events, counts and days when the events happened. The current solution that I have uses two SQL tables:</p>
  
  <p>Events</p>
  
  <ul>
  <li>EventId (int)</li>
  </ul>
  
  <p>EventData</p>
  
  <ul>
  <li>EventId (int) // ref to the Events table</li>
  <li>Date (date time) // stores the day when the data was received</li>
  <li>Count (int) // stores the number of events with that Id from that day</li>
  </ul>
  
  <p>The problem that I'm facing: the EventData table has too much data. If we have X events and Y days for each event, the event data will store X*Y rows.</p>
  
  <p>What other options are there to store the EventData and still be able to do (reasonable) fast reporting on it? I was thinking about actually storing event data as a blob and maybe keep only the last, let's say, 7 days in SQL.</p>