はじめに
現在、「Bubble で自分で Webアプリを作れるようになりたい人 bosyu！2」（長いので、内部的には「 bubble camp」とい呼んでいます。）を行っています。
この中でいろいろな方とお話しさせていただいたのですが、初心者の多くが難しいと考えているのが DB だというお話が上がりました。そこでDB に関する簡単なコンテンツが必要だなと考えて今回の企画を始めました。
ただし、DB に関しては正解というのが正直よくわからないです。
多分、いくつか考えられるパターンがあって、恐らくそのどれでも動くのです。あとはパフォーマンスや保守性をどう考えるか？
テーブルのデータ量にもよりますし、検索して持ってくるデータ数にもよると思います。
どこまで考えるか？というのもありますし、正解がよくわからない以上は、いくつかの事例を紹介して、どういうことを考えて作成しているかを率直に伝えるという方法しかないかなと思いましたので、今回は 「DB事例集」 としていくつか記事を出して行こうと考えております。
なお、DBって何？という人はしんじさんの Youtube が非常にわかりやすいので、先にこちらを見ることをオススメさせていただきます。
それでは、まずは今回、連載中の企画である nosyu の DB について解説させていただきます。
DB事例集１ nosyu
皆さん、こんにちは！
BubbleのDBの事例集として、今回はnosyuの場合を説明します。
nosyuとは？
nosyuは、ノーコードラボがBubble初級者向け講座第２弾として、「bosyuさんもどきをBubbleで作ってみる！！」で作成したサンプルアプリです。
bosyuさんは、ご存知かと思いますが、簡単にSNSで気軽に人材募集ができるサイトです！
募集したいものがあれば、手軽に募集をだせ、それをSNS発信できます。 それを見た人が気軽に応募できるサービスです。
それを見よう見真似で作成したのがnosyuです。
以下が作成過程を示したコンテンツです。（2020/04/21時点ではまだまだ途中ですが）
実際のnosyuは以下↓↓のURLよりご覧ください。
https://nocodelab-bosyu.bubbleapps.io/
DBダイアグラム
早速DBの設計ですが、DBについてはブログではこちら↓↓に書いています。どんなテーブルか、ぐらいしか書いてはいないですが。
nosyuでのテーブルは、以下の４つのみです。
- NosyuData：募集データ
- OuboData：応募データ（募集に対してユーザが応募するときに作成します）
- Message：メッセージデータ（応募するとき、応募に対して返信するとき等に作成します）
- User：ユーザデータ（Bubbleのデフォルトで用意されているデータです）
DBのダイアグラムはこんな感じです。
OuboDataとNosyuDataは１対１で、OuboDataとMessageは１対多です。
さらに、NosyuDataとUser、OuboDataとUser、MessageとUserは１対１の関係になっています。
NosyuData、OuboData、Messageは「Created By」で自動的にBubbleが作成したCurrent Userを設定してくれるので、この項目でUserと紐づいています。
1対多の場合は、その型のListで持たして、1対1の時は、そのDataを持たせば簡単にできます。
BubbleのDBは型がtext、numberだけではなく、Data自体や、リストで持たすことができるのがRDBとは異なるところですね。
ちなみにMessageには「誰宛か」というのがないですが、OuboData、NosyuDataに付随するデータなのでこれらから取得できるようになっています。
DBの設計について
個人的にですが、DB設計の際に考えるのは、
- 拡張しやすい
- 無駄なデータは持たない
- アクセスしやすい
を重視するようにしています。 DBは色々な持たせ方、特にBubbleだと従来のRDBより柔軟なデータ構造が持てると思うので、何が正解かは難しいところですが・・・Bubbleでは特に「アクセスしやすい」を考えます。
例えば、今回一番悩んだのはOuboDataとNosyuDataをどうやって持たすかです。
NosyuDataは募集本体のデータで、一つの募集に対して複数応募が来ることがあります。
なので、NosyuDataにOuboDataをListで持たすのが一般的だとは思います。
しかし、nosyuの画面では、ログインユーザ自身が応募した一覧を表示する画面があり、それを簡単に検索できるために、OuboDataにNosyuDataを持たすようにしました。
もし、NosyuDataにOuboDataを持たせた場合は、NosyuDataのOuboDataのリストから自分が作成したOuboDataを条件にOuboDataを探す、というような条件にしなければならず、もちろん可能ですが、複雑になるかな？と思ったのです。条件が複雑になるほど可読性が低くなるので。
正直、SQLをご存知な方は、こういう場合、SQLの方が簡単なのでは、と思うことあると思います。実際私自身はありました。
ただ、BubbleのDBは柔軟性があるので、「アクセスしやすい」というところから設計すれば、複雑にならないようにもなると思います。何より、修正しやすいので、始めに決めた設計に縛られず、アプリが出来上がるまでは柔軟に変更したらよいと思います！
これはあくまで一つの例ですので、少しのDBだけでも何パターンか設計はあると思います。こんな設計ではダメだな、と思う部分もあるかと思いますが、少しでも参考になれば幸いです。
もう一つの案について
こちらの案はできるだけ「検索をしない」という参照系のパフォーマンス重視の DB構造です。
代償としては、データがいくらか冗長になり、データ追加時の処理に少し時間がかかるようになります。
具体的には、User Type に NosyuData 及び OuboData をそれぞれ List で持つようにします。
これをすると何が良いかというと、Current User's NosyuData で自分が作成した募集のリストを、Current User's OuboData で自分の応募したリストを取ってくることができるようになります。このとき、Do a search for を使う必要がないので、レスポンスは非常に早いです。また、検索条件を考えなくて良いということもあり、恐らくこっちの方がプログラム作るのは簡単ですよね？
しかしながら、元の案に比べると User Type や NosyuData、OuboData という冗長なデータを持つということになるので、保守性という意味ではあまりよろしくないかもしれません。また、NosyuData、OuboData に行を追加した場合には、User Type の方の NosyuData、OuboData にも該当する unique id を入れる必要があるため、データ追加時に処理の追加が必要となります。
また、データ量が増えると場合によっては Do a search for を使った方が速くなったりするケースもあります。
終わりに
とりあえず２案出して、考え方を比較してみましたが、いかがでしたでしょうか？
MVP の時点ではどっちでも大してレスポンスも変わらないと思いますので、やりやすい方で良いんじゃないかと思います。
何を重視するかということで DB の作り方は変わってくると思いますが、ノーコードは改変も容易ですので、色々と試行錯誤してみましょう！
