在 Hacker News 上看到「Database Design for Google Calendar: A Tutorial (databasedesignbook.com)」這個，原文在「Database Design fo Google Calendar: a tutorial」這，這邊的資料庫指的是關聯式資料庫 (RDBMS)，像是常見的 MySQL 或是 PostgreSQL。
而有趣的點是在 Hacker News 的討論，不過還是先帶一下原文的內容。
原文主要就是怎麼設計以及怎麼下 SQL query 會比較好，另外有些「作者經驗」說明為什麼這樣設計，不過這部份很吃場景，所以當作故事聽過去比較好，自己遇到的時候需要通盤考慮；另外有些地方提到的是 trade off，沒有最佳解。
然後回到 Hacker News 上面，在 id=41044011 這邊算給你看，幹嘛用 RDBMS 設計一堆架構：
A random event from my calendar serializes to 740 bytes of iCalendar. An extremely busy calendar containing one event every 15 minutes 9am-5pm 7 days per week only contains 11680 entries for a full year, which works out to around 8MB.
Would suggest instead of designing a schema at all, a calendar is a good example of a problem that might be far better implemented as a scan. Optimizing an iCalendar parser to traverse a range of dumped events at GB/sec-like throughputs would mean the above worst-case calendar could be scanned in single-digit milliseconds.
Since optimizing a parser is a much simpler problem to solve once than changing or adding to a bad data model after it has many users, and that the very first task involving your new data model is probably to write an iCalendar importer/exporter anyway, I think this would be a really great trade off.
因為每個 entry 也不到 1KB (740 bytes)，就算是超級忙的 calendar，每週七天的 9am～5pm 都是每 15mins 一個會議的情況下，全滿也才 8MB... XDDDDDDDD
另外幫他補充說明，他這邊省略掉的是 calendar 接近於 share-nothing 架構，所以每個人直接拆開來獨立存放很容易 scale，你可以用個 scalable key-value solution 存 JSON 就好。
不過文章的原作者主要的目的是找一個大家熟悉但又有點複雜性的東西，示範 database schema 設計的考慮，我不會直接說文章原作者錯啦...
但的確一開始看到文章不會想到暴力解還蠻... 暴力的？XDDD
