カレンダー・システムを構築する際のデータの複雑さに驚いた話

こんにちわ。
 

普段使っているiPhoneのカレンダーはGoogleカレンダーよりもインターフェイスが使いやすいと、改めて感じた、下駄です。
 

何故かって?
 

それは、Googleカレンダーは、まあまあ触った感じがもたつくからですね。
 

本日のIT謎掛け。
 

「スマホのカレンダーアプリ」と、かけまして、
 

「リズミカルなダンスの種類」と、ときます。
 

そのココロは・・・
 

タップするだけです。

カレンダーのデータ登録は、まあまあ複雑

通常カレンダーのデータを考えると、日付(date)と、時間(time)があればいいと考えがちですが、
 

時間が無い、1日中のデータも存在するし、時間がある場合は、開始時間と終了時間が必要な場合もあります。
 

また、日付をまたぐ場合があれば、日付にも開始と終了が必要になります。
 

そして、スマホのカレンダーを登録する場合などは、「繰り返し」の予定というのがあって、
 

毎日、毎週、毎月、毎年、というような繰り返しの他、
 

曜日指定や、毎月○日、毎月第○の曜日、という風に考えると、非常に煩雑な条件も存在します。
 

カレンダーデータの種類まとめ

とりあえず、データ方式を一覧にまとめてみると、
 

 

データベースのスキーマは、いろいろな方法が考えられますが、上記の条件を満たす事を重要視しなければ、今どきのカレンダーシステムとしては、
機能が足りていないと考えられますね。

さらに必要なデータ共有思考

上記のデータ設計ができたら、それを、他人のデータや、何かしらの共通データと合わせて表示できるように、「データ共有」という仕組みが必要になります。
 

「何かしらのデータ」というのは、「国民の休日・祝日」といった、休日は、カレンダーのデフォルトで必要だし、
 

特定のコミュニティの内部で共通するカレンダーデータというのも、必ず必要になるので、上記カレンダーデータ設計の上位に、カレンダー使用者をまたぐデータ設定が必要になります。
 

さらに、共有することを前提に考えると、カレンダーデータそれぞれに、「外部の人に共有公開する、しない」というフラグも必要という風になりますね。
 

いや〜、カレンダーデータ、ナメてたな・・・
 

これらをUIで整えるというのも、まあまあな大きな開発になりそう・・・
 

でも、やってできないことはない。
 

データ設計ができたら、作ってみるとしよう。

Leave a Reply

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です