title: BigQuery for logging events of different types with different properties
body: <p>I want to log events from my client component and analyze them in google's BigQuery. My problem is that the events are of several different types (with potential for more types to be added in the future) - each event type has a different number and types of properties.</p>
  
  <p>For example:<br></p>
  
  <p>{"event":"action",<br>
  &emsp;&emsp;&emsp;&emsp;"properties":{"ts":1384441115,<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"distinct_id":"5EB54670",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"action_type":"pause",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"time":"5"}}<br></p>
  
  <p>{"event":"action",<br>
  &emsp;&emsp;&emsp;&emsp;"properties":{"ts":1384441115,<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"distinct_id":"5EB54670",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"action_type":"resume",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"time":"15"}}<br></p>
  
  <p>{"event":"section",<br>
  &emsp;&emsp;&emsp;&emsp;"properties":{"ts":1384441115,<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"distinct_id":"5EB54670",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"section_name":"end",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"dl_speed":"0.5 Mbit/s",<br>
  &emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;&emsp;"time":"25"}}<br></p>
  
  <p>My question is - how do I handle this diversity in a tabular DB? My reason for choosing BigQuery is its ability to handle big data calculation and analysis of my logged events, but for that to happen I need to figure out the best practice to log these events.</p>
  
  <p>I thought about 2 options:<br>
  1. have a large table that has columns for every property of every event type - in this case every row will contain empty fields.<br>
  2. have a separate table for each event type - this raises two issues - future events will call for new tables, and even worst - I loose ability to perform calculations over all events (seeing as all events share some properties like ts, distinct_id and time) </p>
  
  <p>I'm pretty sure I am not inventing the wheel with my use-case, so I would love to hear about the best practices from you guys. Thanks!</p>
  
  <p>Amit</p>