Bubbleのデータベース設計では、画面から先に作るより、誰が何を登録・閲覧・更新するかを整理すると後からの手戻りを減らせます。Data typeは扱う対象、Fieldはその対象が持つ情報です。
01Data typeを業務の単位で考える
たとえば問い合わせ管理なら「問い合わせ」「顧客」「担当者」を候補にできます。一つの型にすべてを詰め込むと、同じ顧客情報を何度も保存したり、権限を分けにくくなったりします。まず業務で使う名詞を書き出し、各データを誰が作るか確認しましょう。
02Fieldは必要な情報から選ぶ
問い合わせには件名、本文、状態、担当者、作成日などが考えられます。入力時に必須か、後から更新するか、一覧で検索するかも決めます。将来使うかもしれない項目を大量に作るより、試作に必要な項目に絞る方が変更しやすくなります。
03関係と権限を一緒に設計する
顧客と問い合わせの関係を表すときは、画面表示だけでなく検索やアクセス制御の条件も考えます。BubbleではPrivacy Rulesがデータへのアクセスに関わるため、型を決める段階で「顧客は自分の問い合わせだけ見られる」などのルールを書いておきます。
04サンプルデータで検証する
単純な1件だけでなく、同じ顧客の複数件、担当者の変更、退職した担当者、情報が未入力の件も試します。一覧、詳細、編集の各画面で意図した情報だけが表示されるか確認し、構造と権限を調整しましょう。
05具体例：問い合わせ管理の型と項目を決める
架空の問い合わせ管理なら、Data type「問い合わせ」に件名（text）、本文（text）、状態（選択肢）、顧客（顧客への参照）、担当者（Userへの参照）を置けます。「顧客」には会社名や連絡先を置きます。同じ会社から3件届いても顧客情報を毎回本文へ複製せず、顧客への参照で結び付ける設計です。Bubbleでは別のData typeをFieldの型にできるため、この関係を表せます。状態の候補と変更できる人も先に決めてください。
問い合わせ一覧では「担当者が自分の担当分を探す」「顧客が自分の分だけ見る」という二つの検索を想定します。顧客向けに公開する本文と、社内だけの対応メモを同じ画面に置くなら、表示条件だけでなくPrivacy RulesでFieldや検索可能な範囲を分ける必要があります。顧客を別の顧客レコードに差し替えた場合や、担当者が退職した場合にも、誰がその問い合わせを閲覧・再割当てできるか試します。
最初に「この項目は誰が入力するか・誰が読むか・一覧で検索するか」を各Fieldの横に書いておくと、不要な項目を増やさずに済みます。個人情報を含む実データで試す前に、架空の顧客2社、問い合わせ3件で権限と画面を確認してください。
参考資料
内容は公開時点の公式資料をもとに構成しています。仕様は変更されることがあるため、導入時は最新の公式情報をご確認ください。