Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RDB脳からFirestore脳へ

ham
March 07, 2022

 RDB脳からFirestore脳へ

ham

March 07, 2022
Tweet

More Decks by ham

Other Decks in Technology

Transcript

  1. RDB脳からFirestore脳へ
    2022/3/7 LT
    ham

    View full-size slide

  2. Firestoreとは
    ● Firebase(Google Cloud)で提供されているNoSQLデータベース
    ● フロントコードから直接呼び出すことができるため、バックエンドの構築が
    不要。
    ● 料金は保存量+READやWRITE数で決まる従量課金だが、無料枠がありサクッ
    と使うだけであれば無料枠におさまるのでプロトタイプ開発や個人開発での
    使い勝手が良い。

    View full-size slide

  3. RDB脳からFirestore脳へ
    システムでデータの保存先と言えば、PostgreSQLやMySQLなどのリレーショナ
    ルデータベース(RDB)が主流です。
    そのため、システム開発したことがある方はRDBの知識を持っている方が多いの
    ですが、RDBの考え方をFirestoreにそのまま適用するとうまくいかないこと/
    面倒なこと/そもそもできないことが多々あります。
    そこで、このスライドではRDBとFirestoreで考え方を変えるべき例を2つ紹介
    します。

    View full-size slide

  4. アクセス範囲に合わせてテーブルを分ける
    例えばユーザー情報を管理するテーブルを考えます。
    保持する情報は下記の通り。
    ● ニックネーム
    ○ 全体に公開OK
    ● メールアドレス
    ○ 本人のみ閲覧OK

    View full-size slide

  5. アクセス範囲に合わせてテーブルを分ける
    RDBの場合
    usersテーブルに
    nicknameとemailを保持
    users
    ・nickname
    ・email
    バックエンド
    クライアントからバックエンドを通して
    RDBにアクセスするため、同一テーブル
    に入っていてもシステムでアクセス制御
    可能

    View full-size slide

  6. アクセス範囲に合わせてテーブルを分ける
    Firestoreの場合
    usersドキュメントに
    nicknameとemailを保持
    /users
    ・nickname
    ・email
    レコード単位でルールを設定しアクセス
    制御するので1レコードにアクセス範囲
    が異なるデータが入っているとアクセス
    制御が困難
    ルール

    View full-size slide

  7. アクセス範囲に合わせてテーブルを分ける
    Firestoreの場合
    nicknameとemailでドキュメントを
    分ける
    /private_users
    ・email
    /users
    ・nickname
    ルール
    ルール
    ドキュメントを分けることでそれぞれに
    ルールを設定可能

    View full-size slide

  8. 用途ごとにテーブルを作成する
    複数のリソースを持っており、画面によって必要な情報が異なる場合を考えま
    す。
    画面A:usersのみ使用
    画面B:usersとそれに関連するuser_hogesを使用
    画面C:usersとそれに関連するuser_fugasを使用
    画面A 画面B 画面C
    users
    users
    └user_hoges
    users
    └user_fugas

    View full-size slide

  9. 用途ごとにテーブルを作成する
    RDBの場合
    リソースごとに
    テーブル管理
    users
    バックエンドで必要なデータをDBから取
    得して整形して返却
    A
    B
    C
    user_hoges
    user_fugas
    バックエンド
    users
    users
    └user_hoges
    users
    └user_fugas

    View full-size slide

  10. 用途ごとにテーブルを作成する
    Firestoreの場合
    /users
    A
    B
    C
    /user_hoges
    /user_fugas
    users
    users
    user_hoges
    users
    user_fugas
    リソースごとに
    ドキュメント管理
    バックエンドがないため、データの整形をク
    ライアントが実装する必要がある。
    また、RDBのように適切にjoinしてリクエスト
    を減らすことが難しくREAD数も増える
    (READ数課金)

    View full-size slide

  11. 用途ごとにテーブルを作成する
    Firestoreの場合
    /users
    A
    B
    C
    /user_hoges
    (with users)
    /user_fugas
    (with users)
    users
    user_hoges
    user_hogesやuser_fugasに
    users情報を含める。
    クライアントが使いやすい形に整
    形しておく。
    あらかじめクライアントが使いやすい形に整
    形してあるので、クライアント処理がシンプ
    ルになり、READ数も減る。
    user_fugas
    参照処理はシンプルに
    なるが、更新処理が煩
    雑になるのでは?

    View full-size slide

  12. usersが更新された場合
    用途ごとにテーブルを作成する
    /users
    /user_hoges
    (with users)
    /user_fugas
    (with users)
    usersが更新された時、user情報を含んでいるすべてのド
    キュメントを更新する必要がある。
    →クライアントがuser情報を持っているドキュメントを把握し
    ておく必要がある
    →処理が煩雑に・・・

    View full-size slide

  13. usersが更新された場合
    用途ごとにテーブルを作成する
    /users
    /user_hoges
    (with users)
    /user_fugas
    (with users)
    クライアントからはusersのみ更新
    Cloud Functions
    usersの更新を検知して、user_hogesや
    user_fugasを更新
    →クライアントはuser情報を持っているドキュメン
    トを把握する必要がなくなる。

    View full-size slide

  14. 参考書籍
    Firestoreのドキュメントだけでは読み取れない、実践で役立つプラクティスが
    書かれている本。
    私はこの本を読んでFirestore脳ができました。
    Firestoreを使ってみようと思っている方は一読の価値があると思います。
    (ちなみに私はこの本の関係者でもなんでもありません)
    実践Firestore

    View full-size slide