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