【SPIRAL WebTools】後から困らないDB設計｜作成前に確認したいポイントを解説

学生インターンシップです！
スパイラル株式会社の学生インターンとして、SPIRALを学習しながらユーザー目線で質問に答える活動をしています。
補足情報や調査結果を提供を行い、皆様のお役立てができればと思っています！
※学生による調査・補足情報です、参考としてご利用ください。
　正式な仕様や最終的な内容は保証されません。

はじめに

今回ご紹介するのは、SPIRAL WebToolsでDBを作成する前に確認しておきたい設計のポイントです。
SPIRALではフォームやアプリ画面を比較的簡単に作成できますが、最初のDB設計を曖昧にしたまま進めてしまうと、後から「項目を変更したい」「重複登録を防ぎたい」「検索しづらい」といった問題が起こることがあります。
この記事では、SPIRAL WebToolsでDBを設計する際にハマりがちな落とし穴と、その回避方法を初心者目線で解説します！

全体図

こちらが今回ご紹介するDB設計の流れです。

フォームや画面を作成する前に、どのようなデータをどのような形で管理するのかを整理しておくことが重要です。

今回は、問い合わせ管理DBを例にしながら、設計時に注意したいポイントを確認していきます！

今回想定するDB

今回は、問い合わせフォームから送信された内容を管理する「問い合わせ管理DB」を例に考えます。
問い合わせ管理DBでは、以下のような情報を管理することを想定します。

・問い合わせ者の氏名
・メールアドレス
・問い合わせ種別
・問い合わせ内容
・対応状況
・担当者
・添付ファイル

このように、最初に管理したい情報を整理しておくことで、必要なフィールドや検索条件を決めやすくなります。

問い合わせ管理DBの設計例
氏名、メールアドレス、問い合わせ種別、問い合わせ内容、対応状況、担当者、添付ファイルなどを管理する想定です。
詳しいフィールドタイプの例は以下の図で確認します。

Step１：何を1レコードとして管理するか決める

DBを作成する前に、まず「何を1件のデータとして管理するのか」を決める必要があります。
例えば問い合わせ管理の場合、基本的には「1つの問い合わせ」を1レコードとして管理します。

この部分が曖昧なまま進めると、後からデータの管理単位が分かりづらくなります。

例えば、以下のような考え方があります。
・問い合わせ管理 → 1件の問い合わせを1レコードにする
・セミナー申込管理 → 1人の申込を1レコードにする
・顧客管理 → 1人または1社を1レコードにする

最初にレコードの単位を決めておくことで、必要なフィールドも整理しやすくなります。

Step２：フィールドタイプを適切に選ぶ

次に、DBに作成するフィールドを決めていきます。
このときにハマりやすいのが、とりあえずすべての項目をテキストで作成してしまうことです。

名前や部署名のような短い文字列であればテキストでも問題ありません。
しかし、問い合わせ内容や備考欄のように長文が入る可能性がある項目は、テキストエリアなど別のフィールドタイプを検討した方がよい場合があります。

また、メールアドレスを管理する場合は、通常のテキストではなくメールアドレス用のフィールドを使うことで、入力形式のチェックなどを行いやすくなります。

フィールドタイプを選ぶときの確認ポイント
・短い文字列か、長文か
・数値として計算や比較をしたいか
・日付として検索や並び替えをしたいか
・メールアドレスとして扱いたいか
・選択肢から選ばせたいか

Step３：重複登録を防ぎたい項目を決める

DB設計では、重複登録を許可するかどうかも重要です。
例えば、会員登録フォームで同じメールアドレスを何度も登録できてしまうと、同じ人のデータが複数作成されてしまいます。

メールアドレス、会員ID、社員番号、申込番号など、一意に管理したい項目は事前に整理しておきましょう。

ただし、すべての項目を重複不可にすればよいわけではありません。
例えば、同じ会社名の人が複数登録されることは自然に起こります。
そのため、「重複してはいけない項目」と「重複してもよい項目」を分けて考えることが大切です。

問い合わせ管理DBでの例
・メールアドレスだけで重複不可にする場合
　→ 同じ人から複数の問い合わせを受け付けにくくなる可能性があります。

・問い合わせ番号や受付番号を一意にする場合
　→ 問い合わせ1件ごとに管理しやすくなります。

どの項目を重複不可にするかは、「何を一意に管理したいのか」に合わせて考えることが重要です。

Step４：他のDBと紐づける必要があるか確認する

複数のDBを使う場合は、DB同士の関係も事前に考えておく必要があります。

例えば、問い合わせ管理では以下のようにDBを分けることがあります。
・顧客DB
・問い合わせDB
・対応履歴DB

このような場合、問い合わせDBから顧客DBを参照したり、対応履歴DBを問い合わせDBに紐づけたりする設計が考えられます。

DB同士の関係を後から考えると、フィールドの作り直しやデータ移行が必要になる場合があります。
最初の段階で「どのDBとどのDBを紐づけるか」を整理しておくと安心です。

DBを分けるか迷ったときの考え方
・同じ情報を何度も入力している
　→ 別DBとして管理した方がよい可能性があります。

・1件の問い合わせに対して、複数の対応履歴を残したい
　→ 問い合わせDBと対応履歴DBを分ける設計が考えられます。

・単純な問い合わせフォームとして管理できればよい
　→ まずは1つのDBで管理する方法でも十分な場合があります。

Step５：検索や一覧表示で使う項目を考える

DBはデータを登録するだけでなく、後から探しやすい形にしておくことも重要です。
そのため、どの項目で検索したいか、どの項目で並び替えたいかを事前に考えておきましょう。

例えば問い合わせ管理の場合、以下のような項目で検索することが考えられます。
・対応状況
・問い合わせ種別
・登録日
・担当者
・メールアドレス

フォームを作る前に、運用時にどのようにデータを探すのかを想像しておくことが大切です。

検索項目の例
・未対応の問い合わせだけを確認したい → 対応状況
・特定の種類の問い合わせを確認したい → 問い合わせ種別
・最近登録された問い合わせを確認したい → 登録日
・自分が担当している問い合わせを確認したい → 担当者

Step６：DB作成前に設計内容を見直す

ここまで整理できたら、実際にDBを作成する前に設計内容を見直します。
特に、フィールドタイプ、重複登録の制御、DB同士の関係、検索条件は後から修正しようとすると手間がかかる場合があります。

DBを作成する前に一度立ち止まり、運用時に困らない設計になっているか確認しておくことが大切です。

DB作成前の確認ポイント
・1レコードの単位は明確か
・必要なフィールドに漏れはないか
・フィールドタイプは用途に合っているか
・重複を防ぎたい項目は決まっているか
・他のDBと紐づける必要はあるか
・検索や一覧表示で使う項目は整理できているか

よくある落とし穴と回避方法

最後に、DB設計でハマりやすいポイントをまとめます。
設計に迷ったときは、以下の内容を確認してみてください。

DB設計でよくある落とし穴
・すべての項目をテキストで作成してしまう
　→ 用途に合わせて、メールアドレス、日付、数値、セレクトなどを使い分ける

・重複登録を防ぎたい項目を決めていない
　→ メールアドレスや会員IDなど、一意に管理したい項目を事前に整理する

・DB同士の関係を後から考えてしまう
　→ 顧客DB、問い合わせDB、対応履歴DBなどの関係を先に整理する

・検索や一覧表示で使う項目を考えていない
　→ 対応状況、問い合わせ種別、登録日、担当者など、運用時に探したい項目を決めておく

まとめ

今回は、SPIRAL WebToolsでDBを設計する際にハマりがちな落とし穴についてご紹介しました。

DB設計では、最初に「何を1レコードとして管理するのか」を決めることが重要です。
そのうえで、フィールドタイプ、重複登録の制御、DB同士の参照関係、検索に使う項目などを整理しておくことで、後から修正が必要になるリスクを減らすことができます。

フォームやアプリ画面を作り始める前にDB設計を確認しておくことで、より運用しやすいアプリを作成しやすくなります。

皆様もSPIRAL WebToolsでアプリを作成する際は、ぜひDB設計から意識してみてください！