[whatgaul]

This project grew out of our interest in understanding and optimizing time spent in meetings, but don't let that stop you from using it some other way. We're providing direct access to a MySQL database specifically so you can slice the data however you like, with any tool you please.

Questions? Feedback? All very very welcome!

[paulryanrogers]

Sqlite please. Or DB-agnostic SQL.

[luuuuk]

Thanks for your input! As future features require continuous syncing between calendar data and the database, SQLite is not really an option.

We chose MySQL based on the following requirements:

- It should be easy to write data to a database created by us, or hosted (on-premise) by a customer due to the sensitive nature of the data (which excludes Google Cloud Spanner and Amazon Aurora)

- As the purpose of this data is analyzed, the DB should be compatible with most BI tools (which excludes SQLite)

- There should be no vendor lock-in

- Due to the analysis purpose of this tool, we prefer a database that focusses on read performance vs write performance (MySQL > PostgreSQL)

- The Calendar Events table can grow long and we don't anticipate it getting wide, which favors row-based databases vs column-based databases (MySQL > Redshift)

- I personally use the WITH and WITH RECURSIVE statements a TON when doing analysis which originally excluded MySQL, but with the launch of MySQL 8, that no longer was an issue.

- We can easily build export functionality to SQLite

For all these reasons, we thought (and think) that MySQL 8 fits the use case quite well and we can relatively easily support other RDBMS databases if needed. Would love to hear your thoughts!

[opless]

Agreed. Like PHP, MySQL really ought not be used in production systems.

(Also just because LAMP stacks are popular, it doesn't mean they're much more than toys)

[slifin]

I've had a look at the database schema and data but there's no data for the recurrence_id field since google calendar can express an infinite set of recurrences how is this represented in the database structure?

[whatgaul]

Right, naturally none of the rocket launches in the demo data set are recurring (perhaps one day...). In another calendar with recurring events, that ID will be a consistent string across all events that are part of the same series. It's pulled from the `recurringEventId` field in the Google Calendar API: https://developers.google.com/calendar/v3/reference/events#r...

At the moment, the tool just syncs events from one month in the past through one month in the future, so it will pick up a finite subset of a potentially infinite series of recurring events. In future iterations, we imagine users defining their own timeframe to sync.