概要

去年度からFirestoreを使用した際の個人的な雑感を示します。

構造の説明

　Firestoreには「collection」「documnet」「field」という括りがあります。　　

　「collection」には一つ以上の「document」が必要となります。「document」にはユニークIDが設定でき（自動生成も可能）、および様々なデータ型の「field」を設定できます。また、「dpcument」には「サブcollection」を設定できます（以下の構造を参照）。「fierd」は言ってしまえばmap（pythonであればdictionary）と同義と考えていいです。

collection-main
 |-<document-1>
 |   |-field-key：field-value
 |   |-field-key：field-value
 |   `-collection-sub
 |      `-<document-1.1>
 `-<document-2>

DBの設計

　基本的には「collection」をRDBのテーブルと同義と考えて良いと考えています。「サブcollection」には、「document」に紐づく情報を強く紐づけることが出来ます。個人的には、親になる「document」を削除する際、と一緒に削除したい情報については「サブcollection」として登録すると良いと思います。

　例えば、ブログ用のDBを対象とし、基本的なテーブルとして「ユーザ」「記事」二つがあるとします（もっと必要なテーブルがあると思いますが、今回は簡略化します）。自分であれば以下のようにします。

ユーザ(collection)
 |-ユーザ１(document)
 |   |-名前：<value>
 |   |-Emailアドレス：<value>
 |   `-記事(collection)
 |      `-記事１(document)
 |          |-タイトル：<value>
 |          `-内容：<value>
 `-ユーザ2(document)
    ・（ユーザ1と同様に続く）
    ・
    ・

　基本的に結びつきが強いものについては、何も考えずに「サブcollection」で良いと思います。ユーザが共有するような情報は「ユーザcollection」とは違う「collection」を用意すればよいと思いました。

ちょっと困ったこと

　documentを削除する際、それにぶら下がるサブコレクションの内容は削除されない点は少し面倒に思いました（この場合、ユーザの「field」は削除されるけど、記事は削除されない）。fieldの内容を増やしたい際は、構造を整形する際にはそれ用にスクリプトを作成しないといけないのかなと思いました（これはあまり気にしなくてもいいかもしれませんが）。あとは、バックアップはCloud storageに入れるにしてもそれ用にスクリプトを作成しないといけないと思いました。