データベースとは？アプリを作る人のための入門ガイド

データベースは、アプリが保存し、読み出す、整理された情報の保管場所です。利用者、注文、予約、メッセージなどが入ります。ブラウザのタブにだけ残っている情報と違い、データベースのデータはページを再読み込みしても、再起動しても残り、アプリを使うすべての人が同じレコードを見ます。ほとんどのデータベースは、スプレッドシートのシートに似たテーブルでデータを整理しますが、データの一貫性を保つための厳格なルールがあります。

AIで作るときにデータベースが重要な理由

AIで作る人がよく驚くのは、完成しているように見えるのに、すべてを忘れてしまうアプリです。顧客を追加してページを再読み込みすると、顧客が消えています。これは通常、アプリがデータをデータベースではなく、ブラウザのメモリに保存していたことが原因です。

また、データベースは、あなたが意識していなくても、最も重要な判断が行われる場所でもあります。

• 何を記録するか。 予約のステータスを保存していなければ、どの予約がキャンセルされたかを表示できません。
• どう結び付くか。 1人の顧客が複数の予約を持てるのか、1つの予約に複数のサービスが付くのかといったことが、アプリ全体の形を決めます。
• 誰が何を見られるか。 プライバシーに関する問題の多くは、利用者がどのレコードを読めるかに関するものです。

データベースを自分で設計する必要はありません。ただ、基本を理解しておくと、データを明確に説明でき、問題を早い段階で見つけられます。

身近なたとえ

小さな事務所の、よく整理されたファイルキャビネットを思い浮かべてください。

各引き出しには1種類のものが入っています。顧客用の引き出し、予約用の引き出し、請求書用の引き出し、といった具合です。各引き出しの中では、すべてのフォルダーが同じ形式に従い、同じ項目が記入されています。各フォルダーには固有の管理番号があり、請求書が顧客のものである場合、請求書のフォルダーにはその顧客の全ファイルをコピーせず、顧客の番号を書いておきます。

これがリレーショナルデータベースです。引き出しがテーブル、フォルダーが行、記入項目が列、管理番号が主キー、別のフォルダーを指す書き込みが外部キーにあたります。優れた事務所長は、「日付のない予約は不可」「同じ番号の顧客は2人まで」といったルールを守らせます。データベースも同じように、ルールを強制します。

具体例：美容室の予約アプリ

AIに、美容室の予約サイトを作るよう頼んだとします。妥当なデータベースには、4つのテーブルがあるでしょう。

services（サービス）

staff（スタッフ）

customers（顧客）

bookings（予約）

bookingsテーブルを見てください。レナの名前や電話番号を、予約ごとにコピーしてはいません。customer_id = 101を保存しているだけです。レナが電話番号を変えたら、変更は1か所で済み、すべての予約に新しい番号が表示されます。これがリレーショナルデータベースの中心的な考え方です。各事実は一度だけ保存し、そこへリンクします。

同じ構造で、次のような有用な質問に答えられます。

• 「金曜日にオマーの空いている時間帯はどこか？」→ その日のオマーの予約を調べる。
• 「今月のカラーの売上はいくらか？」→ 予約とサービスを結合し、料金を合計する。
• 「90日以上予約していない顧客は誰か？」→ 顧客と最新の予約を比べる。

主な用語

データベースの種類

起業家や小規模ビジネスが最初に作るほとんどのものには、リレーショナルデータベースが安全な初期選択です。

データベースはアプリのどこにあるか

訪問者が直接データベースとやり取りすることはありません。訪問者のブラウザにあるページ（フロントエンド）が、通常はAPIを通じて、サーバー（バックエンド）にデータを要求します。サーバーは誰が要求しているか、その人に許可があるかを確認し、データベースに問い合わせて、その人が見てよいものだけを返します。

この中間の手順が重要です。ブラウザがフルアクセスでデータベースに直接問い合わせられるなら、誰でも開発者ツールを開いてすべてを読めてしまいます。

よくある間違いと誤解

• データをブラウザにだけ保存する。 ブラウザのストレージ（localStorageなど）は、1台の端末と1つのブラウザの中にしか存在しません。記憶された絞り込み条件などには構いませんが、注文を保存するには向きません。
• すべてを1つのテーブルに詰め込む。 1つの「予約」テーブルに、顧客の名前、電話番号、サービスの価格をすべての行にコピーすると、すぐに食い違いが生じます。
• パスワードを平文で保存する。 パスワードはハッシュ化して保存すべきで、読める形で保存してはいけません。認証とはをご覧ください。
• データにルールを設けない。 必須項目や一意性のルールがないと、日付のない予約や、重複した顧客が発生します。
• 削除のことを考えない。 顧客を削除したときに、その予約も削除するのか、残すのか、あるいは削除自体を禁止するのかを決めてください。
• 本番のデータで試す。 危険な変更は、まず安全な場所で試し、バックアップを取っておいてください。
• スプレッドシートを永遠にデータベースとして使う。 スプレッドシートは始めるには最適ですが、多数の同時利用者や権限の管理には向きません。スプレッドシートをアプリに変える方法をご覧ください。

AIビルダーに依頼すること

• 「この情報はブラウザではなく、データベースに保存してください。どのテーブルを作るか教えてください。」
• 「スキーマを、各テーブル、その列、それらの結び付きがわかるシンプルな表で見せてください。」
• 「1人の顧客は複数の予約を持てます。各予約は必ず1つのサービスと1人のスタッフに紐づきます。」
• 「顧客のメールアドレスは必須かつ一意にしてください。」
• 「同じスタッフの予約が重ならないようにしてください。」
• 「予約をすべて見られるのはログインしたオーナーだけにしてください。顧客は自分の予約だけを見られるようにしてください。これはサーバー側で強制してください。」
• 「サービスを削除しても、過去の予約は削除しないでください。代わりにそのサービスを無効扱いにしてください。」

Mythexでのデータベース

アプリがデータを保存する必要があるとき、Mythexはプロジェクトに専用のPostgresデータベースを追加します。チャットで「待機リストの登録をデータベースに保存して」と依頼するか、/databaseコマンドを使えます。接続情報はアプリに自動的に渡され、エージェントがテーブルを作成します。データベースは5分間アイドル状態が続くとスリープし、次のリクエストで目を覚まします。公開後の利用料金は、データベースが起動していた時間に対して、構築時と同じクレジット残高から課金されます。FreeプランとProプランで利用できます。詳しくはデータベースのドキュメントをご覧ください。データ駆動型の出発点として、アプリのテンプレートも用意しています。

よくある質問