【ノーコードでも最重要】DB設計について、現役エンジニアに聞いてみた
先日、僕が所属するBubble Japan Communityの活動の一環で、現役のサーバーサイドエンジニアさんに、データベース設計についていろんな話を聞きました。
とても参考になったので、ノーコーダーの方に、初心者エンジニアの方に向けて、この場で共有します。
（宣伝）
Bubble Japan Communityでは、Bubbleを日本で普及させるため、様々な活動を行っています。
ドキュメント日本語化や、最近はプラグインを日本語化して一覧表示しました。ぜひご利用ください。
教えてくれたエンジニアさん
今回は、たなけんさん（@tanaken0515）が教えてくださいました。
SUZURIやbosyuに携わっているそうです！
どちらもよく知ってるサービスだったので、ビックリです笑
テーブルを分ける理由
DBを設計するときは、リレーションを使ってテーブルを分割します。
これがExcelなどとの大きな違いであり、初心者が混乱しやすい部分です。
そもそもなぜ分割するのか。
それは、データを管理しやすくするためです。
何でもかんでも1つのテーブルにまとめると、データが管理しにくく、結果バグりやすくなります。
--
例えば注文管理テーブルに、注文日や支払い方法の他に
・ユーザーの名前・住所・年齢
・商品の名前・作者・金額
などが入っているとします。
この状態だと、どんな情報が入ったテーブルか把握しづらいです。
また、毎回全ての情報に書き込みが発生し、処理が重くなります。
この場合は、ユーザーテーブル、商品テーブル、注文管理テーブルに分割することができます。
--
理想は、テーブル名のみで役割が理解できること、だそうです。
・ユーザーテーブルなら、ユーザー情報が入る。
・商品テーブルなら、商品情報が入る。
と、一目で理解できますよね。
こうすることで混乱せず、整理してデータ管理ができます。
問題なく動けば、それでよし
とはいえ、DBを完璧に最適化しようと、設計に時間をかけすぎるわけにもいきません。
色んな考え方はありますが、たなけんさんは「まずは動くものを作って、動かしてみる。そして問題を見つけたり壁にぶち当たっては改善していく」という、未来の改善を前提とした上で
「問題なく動けば、それでよし」という考えでした。
これはわりとノーコードでも似た考えだと思うので、共感する方も多いのではないでしょうか。
ただし、設計の優先順位をつけることは重要です。
例えば、商品の在庫情報であれば最悪、店舗の実物を見て修正できます。
しかし、注文履歴はデータのみしか残らないため、もし不具合で消えると困ってしまいます。
この場合、注文履歴は優先して丁寧に設計する必要があります。
力の入れどころを見極めて、ほどよく設計に労力をかけるのがベストですね。
DB設計おすすめ書籍
たなけんさんによるDB設計の推薦図書です。
図解が多い印象なので、分かりやすそうですね！
DB設計手順・ツール
これも人によりますが、たなけんさんの場合は以下手順だそうです。
①紙やホワイトボードで自由に書いて考える
②共有が必要であれば、図に起こす
③DBを組み始める
いきなりツールを使うより、制約なく自由に書く方がやりやすいそうです。①が下書き、②が清書、のイメージかと思います。
--
また、②用の作図ツール「PlantUML」を教えてもらいました。
テキストで書いた内容を、図にしてくれるツールだそうです。
絵で描くと、どうしてもサイズや矢印の傾きを調整したりで時間がかかりますが、このツールを使うことでかなり時短できるそうです。
僕はいつもdraw.ioで描いていますが、これは慣れるとかなり早そうなので練習します！
プログラミングに近い書き方っぽいので、抵抗ない方は使ってみると良いですね。
--
そして描いた図は「esa.io」で共有するそうです。
マークダウンで記述し、ドキュメント内に図がそのまま埋め込まれるそう。
慣れている方なら、こちらも便利ですね。
ノーコーダーであれば、PlantUMLの図を画像で落とせるならNotionなどでも使えるので、それでも良さそうです。
おわりに
今後BubbleやAdaloの可能性が広がり、開発規模が大きくなった場合に
DB設計は避けては通れない道となります。
難しい部分ですが、コツコツ勉強したり試行錯誤して、どんどん慣れていこうと思います。
そしてチーム開発の際など、情報共有をスムーズに行えるようになりたいです。
たなけんさん、そして声をかけてくださったBubble Japan Communityの頭である、おーみちさん、ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？