タイトルのとおり、Zoomにて開催された
「【ノーコード分科会】No-Codeの「DB設計」について語ろう!~Bubble会~」
に出席しました。
【ノーコード分科会】No-Codeの「DB設計」について語ろう! ~Bubble会~
No-Codeツールは多種多様なものが世に出てきました。
しかし初心者が必ずと言っていいほどぶつかる壁が「データベース(DB)設計」の部分であるとのこと。
このBubble会では、データベース設計の話を中心に、初心者がNo-Codeツール(特にBubble)利用時につまずきやすいポイント・おすすめの解決方法などをざっくばらんに語られました。
Bubbleとは、No-Codeツールの中でも最も汎用性の高いwebアプリケーション制作ツールです。
※ 用語等、正確でない記載がある場合があります。(私自身DB設計弱いです…)
目次
追記: 「【ノーコード分科会】No-Codeの「DB設計」について語ろう! 〜Bubble会〜」のノーカット動画はこちら
本記事にて書き起こしを行いましたZoomセミナーの録画動画が公開されました。
ノーカット版にて約2時間30分ほどの長編となりますので、本記事の書き起こしをご参考にしていただくか、YouTubeの目次リンクを活用して必要な箇所をご覧ください。
以下はこちらの動画の書き起こしになります。
導入: No-Code開発ツールのおすすめ利用ステップ
No-Code初心者の方がNo-Code開発ツールを選定する場合は
Glide(シンプル) → Adalo(中間) → Bubble(少し複雑) の順番に進んでいくのがおすすめ。
• AdaloのDBは、独自のデータベースシステムが用意されている
• 1対多、1対1、等をあまり考えなくてよい
• Glideで物足りなくなった人が、Adaloへ、その後Bubbleへ進んでいくイメージ
Create an App from a Google Sheet in Minutes · Glide
関連記事: Glideでログインユーザーごとに表示切り替えできるアプリは作れるか | まほウェブ
Glideでログイン機能・ユーザーごとに表示切り替えできるアプリは作れるか
次はAdaloを触ってみたいところ。汎用的である程度何でも開発できそうな印象ではやはり、Bubbleですね。
No-Code初級〜中級者の方におすすめなノーコード開発アプリ”Adalo”
直感的に開発できるUIとシンプルな使いやすさを持ちつつ、会員登録・ログイン機能のある汎用性の高いアプリを開発できるのが”Adalo”です。
Adalo – Build Your Own No Code App
Adalo では、コードを書くことなしに、簡単にアプリを作ることができました。
ただし、この「簡単」は、ある程度アプリ作成(少なくともデータテーブル間の関係を理解できる)に馴染みがある方にとっての「簡単」です。
全くの素人が Adalo を使用してアプリを作成するには、少しハードルが高いかもしれません。
しかし逆に言えば、ある程度の素養があって、アプリのアイディアがある。かつコードを自分で書くのは難しい・・・という方にとっては非常に強力なツールになります。
このブログで良く紹介している bubble よりは扱いが簡単だと感じましたので、テンプレートの改変程度で十分、と感じる方は試してみてはいかがでしょうか?
ノーコードでウェブアプリ、ネイティブモバイルアプリが作れる!Adalo の使い方 – ノーコード ラボ
有料プランに加入すれば、AdaloをネイティブアプリとしてApple App Store, Google App Storeに公開させることが可能です。
参考記事: Adaloをネイティブアプリとしてストア申請するための3つの下準備
参考記事: Adaloをネイティブアプリとしてストア申請: Google Play Store編
参考記事: Adaloをネイティブアプリとしてストア申請: Apple App Store編
ノーコードツールでのモバイルアプリ開発は「遅い」「速度・パフォーマンスが不十分」と言われることが多いのですが、Adaloは2022年パフォーマンス改善に取り組み、十分実用にも耐えられるレベルになってきています。
参考: Adalo’s Performance Updates
BubbleのDBテーブル設計の良さは「作りながら考えることが出来るところ」
LIBRIS大道さん:
本来データベース設計は難しい。
Sier業務では、テーブル設計書を書いてエンジニアに指示していた。
• 桁数をどうするか
• nullを許すか
等、要件定義段階で考える必要があることが多く、難しい印象。
その点、Bubbleはあまり気にしなくてよい。
• 0や空白でも動いたりする
• データ型
• 小数点等
• 他のテーブル参照
• リスト型で復数持たせたりもできる
ただし、Glideよりは時間はかかってしまう。
NoCode NInjaさん:
本来、DBは一度設計したら、あまり修正するべきではない。しかし、Bubbleだと気軽に後からでもやり直しができる。
動くかどうか入れてみて、やりながら考える方法でOK。
初心者がNo-Codeでデータベース設計・構築をする際、どのあたりでつまづきやすいか?
しんじさん:
自分自身の経験では、4つのつまづきがあった。
1: DB設計を決めたあと、DBのデータ型(?)を変えたときに、データがいい感じにならない。
例: 初期値の設定を後から変えると、既存のデータで空白の箇所が初期値のようにならない
→ 現在では修正されたとのこと
2: ランダムでデータを取得するときに、処理が重くなった。
DB処理順序を変えることで、トライ&エラーで高速化できた。
例) おみくじ: ランダム処理をページ遷移の前にするか、後にするかによって処理速度が大きく異なった。
DB構造を変えなくても、速度を改善できることは多い。色々と試してみるべき。
3: DB内データの削除
通常のデータベース設計ではdeleteフラグをつけることで削除したとみなす運用をすることが多い。
Bubbleでもそのような運用を心がけるべき。
Bubbleでは、削除処理をすると完全にデータ削除されるので
回避策としてDeleteFlagを用いる(Yesなら非表示)
※あぽとさんにご指摘いただいて修正いたしました。ありがとうございます。(2020/05/02)
4: 初期データをまとめて入れることができない。
有料機能。ただしZapierを絡めると無料でもできる方法があるとのこと。
※ integromat・spreadsheetとのBubble連携
上記のように、トライ&エラーで解決していくことが必要。
NoCode Ninjaさん:
DBは、本来切り離されて設計されることが多い。
ページエレメントを設計した後に、DBを触ることが多いはず。DBは、ページエレメントとは別物であくことを認識すべき。
たとえば、DBも別でdeployする必要がある。
No-Codeは基本的にはGUIで何でもできるイメージだが、基本的にはフロント側をドラッグ&ドロップするのみで、DBは別途に考えていく必要がある。
プラットホームごとの癖がある。プラットホーム上のルールを把握することが大切。
Bubbleではワークフローの設定が難しいと感じる方が多いはず。
LIBRIS大道さん:
食べログのお気に入り機能をもつようなアプリを制作しようとした際の話。(No-Codeではなく、スクラッチ制作を指示)
本来は「お気に入りテーブル」を作るべきところ、ユーザーテーブルにお気に入りデータをコンマ区切りで追加するよう設計してしまった。
結果、アプリは意図するような設計や動作とはならなかった。
テーブル同士の関係性を、いかに自分の中で理解していくかが大切。
Bubbleだと、トライ&エラーができるので、テーブル同士の関係性を、作りながら確認していくことが出来る。
注意するポイントとして、検索が遅くなってきたりすることがある。
動作を良くするテーブル設計に関しては、別途勉強していくこともいいかも。
ノーコード ラボさん:
画面の中の要素を、いかにDBに落とし込んでいくかが最初につまづきがち。
画面とDBとの連携が自分の中で上手く描くことが難しいかも。
テーブル同士に階層構造を持たせようとすると、途端に難易度が上がる。
初心者は「事例をまだ知らない」ということが、難しく感じる1つの要因である。
DBを上手く設計したいのであれば、急がば回れで、まず事例のマネをして設計してみるといいかも。
No-CoderがアップロードしているYouTube(しんじさんのNoCode Schoolなど)や、ノーコード ラボのブログなど。
まずは真似をして事例を知っていくところから。そちらのほうが結果的に近道になる。
新規サービスを作っていく際のデータベース設計フローについて
Sho Tさん:
ER図を書いてみよう、という話も出たりはしていたが…
まずエンティティを抽出し、そこからユーザー属性や行動を紐付けていく
しんじさん:
「データベース設計 やりかた」で調べてみる。
エンジニア向けの記事ではあるが、Bubbleでの設計時にも
自分が作りたいサービスの「エンティティ」を抽出する。
エンティティとは?
→ ざっくり言うと、どういうプレイヤーがそのサービスにいるのか?ということ。
たとえはUberだと、ドライバー・乗客。(など)
→ それらのユーザー(エンティティ)がどのような属性をもち、どのように行動していくのか?を紐付けていく。
それらを実際にExcelにデータをいれてみる。
何度も出てくるデータは他のテーブルに分けたほうがよい。(=正規化)
質問: エンティティの抽出に慣れるまでに参考にしたほうがよいテンプレートなどはありますか?
しんじさん:
「データベース 構成」「データベース 事例」などで調べてみること。
ただし、人のDB構成をみるのは、かなりエネルギーがいる。
自分が作りたいシステムについてまず、自分自身で構成を考えてみる。手を動かす、頭を動かす。
そのあとに、他人のDB事例をみていくと理解しやすくなることが多い。
No-Codeツール(Bubble)におけるDB設計で、難しいシチュエーションとは?
どのような設計が難しいDB設計となりうるか。
NoCode Ninjaさん:
どのようなセッティングが難しいDB設計となりうるか。
要件定義の段階の話。
ノーコード ラボさん:
たとえば、階層構造を持たせようとするとき。何段階もテーブルが繋がってくると難しい。
あとはパフォーマンスをどこまで考えるかによる。
最もシンプルなのは、検索をしないことだが…。
Do a Search forにすべきか、Filterにすべきか
ノーコード ラボさん:
個人的には、階層構造をもたせるのが高速化につながるとは思っている。しかし、階層構造の設計が初心者の方にはハードルが高いだろうので、悩ましいところ。
Bubbleでリピーティンググループを使う際には、基本的には別テーブルをもたせる。
リピーティンググループとは
= DBから繰り返し処理でデータをもってこれるエレメント?(Bubbleの中のエレメントらしい)
DB事例集が3つノーコードラボのブログにあるので、参照してほしい。
DB設計からみたBubble制作フローについて
アバウトに作ってみて、一旦すべて壊す
ノーコード ラボさん:
画面はまずアバウトに作る。その状態で、DBを作っていく。
ざっくり画面やDBを設計したあと、一旦すべて壊す。
その後、新しく作り直すと良い。
アバウトに作った画面・DBのものを作り込んでいくより、一旦アバウトに作っていき、頭の中で設計図を描いてから再度新規に作り直していくほうが結果的に速くなる。
高速化のために、カレントユーザーからデータを引っ張って来られるような設計にすべし
いかにカレントユーザーからデータを引っ張ってこれるか。出来るだけカレントユーザーからデータを持ってこれるように設計すべし。
current user ~とすることによって、検索対象を指定することができる。Do a Search forを使ったあとの結果が、current userの方から見えている。
設計するときも、current userの~として設計するほうが、わかりやすいはず。
current user’s item等とすることで、既に1段階絞り込んで検索をかけることができるので、処理が軽くなる。
サーチとフィルタの違い。処理速度の観点から
サーチとフィルタではどちらが速いのか
基本的には、高速な順番
(高速) < (低速)
検索しない < Do a Search for < Filter
Do a Search forは、サーバーにクエリをなげて、サーバー側に処理させている。
FilterはDBからデータをもってきて、クライアント側で処理をしている。
データ量の問題
Do a Search for を使うことによって、検索対象のデータ量を制限できる
どれくらいの量のデータを、アプリに持ってくるかによって速度が異なってくる
フィルタを使ったほうが良いケース
持ってきたデータを何かのグループごとに集計したい場合など
例) Excelのsubtotal
Filter = 一度、データをすべてもってきている。その持ってきたデータの中を、さらに検索したい場合。
1回出してきた条件に対して、さらに絞り込んで検索・処理したい場合。
たとえば並び替え(ソート)。一度もってきたものに対して処理を加えたい場合。
Do a Search forでもってきたデータに対して、フィルタをかける際にFilter機能を使えばOK
昨日話題に上がった
Bubble 「Do a Search for」と「Filter」について僕のTanonchaで例えると、
1⃣名前が入力されている飲食店情報を取得し、Repeating Groupでリスト表示
(Do a Search for)2️⃣ユーザーの操作で、更に「ラーメン店」のみで絞込み
(Filter)一例として、こういうイメージかなと。
— あぽと@コードを書かないWebアプリ制作 (@apopotoapoto) May 2, 2020
データベース設計に関しては、事例を当たりながら手を動かしてみることが重要
いかがでしたでしょうか。
「とりあえずやってみる・触ってみる」ということがよく叫ばれるNo-Code界隈ですが、データベース設計に関しても、事例を学ぶという点は必要なものの、大枠の考え方としては同じようです。
• 自分が作りたい事例のDB設計をまず自身で考えてみる
• 似た既存のDB事例を調べてみて、良いと感じた構成を取り入れる
• 制作する際は、まずアバウトに作ってみたあと、一旦すべて壊してから再度作りなおす
• DB処理パフォーマンスが最適なものになるようチューンナップしていく
特にこのあたりが、No-Code制作をしていく上でのDB設計で大切な心構え・方法となってきそうです。
No-Codeツールにおけるデータベース設計・構築をマスターして、ノーコードでのwebアプリ制作をマスターしていきましょう!
追記: データベース設計を学ぶには、勉強としてNo-Codeツール「AirTable」を触ってみるといいかも
マスターテーブルを一つ作るだけで、会員向けのカレンダー&簡易Listが作れるAirtableは、すごいと思うんですよ。自動化ツールとの連携とか、まさに「Airtableを制する者はNoCodeを制す」という感じ。データベースの仕組みを知っているか?知らないか?で見える世界が全然違ってきます。 pic.twitter.com/FbAi1B38v9
— tsubasa@NoCodeCamp (@tsubasatwi) May 10, 2020
AirTableは、データベースの操作を直感的なものにしたNo-Codeツールです。
小難しいデータベースと違い、GoogleスプレッドシートやExcelの操作感で簡単に使用できます。操作感はExcelのままで、入力チェックや絞り込み、複数シートにまたがるデータの整合性チェックは一般的なデータベースの機能になっているので、Access+Excelというイメージです。
AirTable:直感的にデータベースを使えて業務システムに最適|あんどう|DXとNoCode|note
Bubbleが採用しているものと同様、リレーショナルデータベースのNo-Code版となっています。
Excelの感覚で数値やデータを入力することができ、たとえば表示形式を切り替えることで入力フォームやカレンダー表示などをワンクリックで実現することができます。
いきなりBubbleでデータベース設計をするのは少しハードルが高そう…と感じた方は、AirTableでデータベースに特化して触ってみると感覚が掴めてくるかもしれませんね。
基本的な機能は無料で利用することができます。データベースの勉強にぜひ活用してみてください。
データベースが内蔵されているノーコードアプリ”Adalo”も初心者〜中級者におすすめ
他にも、冒頭でもご紹介したNo-Codeツール「Adalo」もBubbleの前段階として良いかもしれません。
WebサイトやPWA、アプリをとりあえず作ってみたいという方、#Adalo という #NoCode ツールがあります。
今の時代はスマホへの対応が必須+自分である程度いじって作りたいという感覚ですと良い感じにハマるかと思いますので、是非触れてみてください☺#起業しろ#デイトラhttps://t.co/DBhQxUcERz— NoCode Ninja@オンラインサロン運営中 (@nocodejp) May 11, 2020
Adaloはデータベース内蔵型のWebアプリ開発ノーコードツールなのですが、外部データベースとしてAirtableと連携が可能です!
詳細は下記の記事より說明しています。ぜひ併せてお読みください。
Adaloの外部データベースとしてAirtableと連携。API接続方法 | まほウェブ
Adaloの外部データベースとしてAirtableと連携。API接続方法
ステップバイステップでいろいろな概念に慣れていきながら、作りたいWebアプリケーションをノーコードで実現できるようになっていきましょう。
さらに追記: ノーコードのためのデータベース学習・勉強におすすめな書籍・本・動画をまとめました
ノーコード開発のためのデータベース設計学習おすすめ本・書籍&動画 | まほウェブScript
↑の記事にノーコードのためのデータベース学習ロードマップ、おすすめ教材をまとめました!ぜひ読んでみてください。
Leave a Reply