エンジニア入門研修

用語解説

第10章 データを保存できる形にする

この章では、整理した業務の言葉やルールを、データベースに保存できる形へ変換する。ここで出てくる用語は、RDBやSQLの基礎として研修の外でもそのまま通用する。テーブルや制約からSQL操作、トランザクションやマイグレーションまでを、基礎から順に解説する。

SQL

  • 読み：エスキューエル／シークェル（Structured Query Language）
  • 一言で言うと：データベースに保存、取得、更新、結合、絞り込みを指示する言語。
  • くわしく：SQLはリレーショナルデータベースを操作するための共通言語である。テーブルの形を作る命令も、データを出し入れする命令も、すべてSQLで書ける。アプリケーションは内部でSQLを発行してデータを扱う。SQLが書けると、設計したテーブルが実際にユースケースを満たすかを自分で確認できる。
  • 具体例：支援ステータス機能で、メンターの担当受講者一覧をSQLで取得して、設計が正しいか確かめられる。
  • つまずきやすい点：DBMSごとに方言があり、SQLiteで動いたSQLがPostgreSQLでそのまま動くとは限らない。
  • 関連語：DDL（第10章）、DML（第10章）、SELECT（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

RDB

  • 読み：アールディービー（Relational Database）
  • 一言で言うと：データをテーブルと関係として扱うデータベース。
  • くわしく：RDBは、同じ種類の事実をテーブルにまとめ、テーブル同士を関係でつなぐデータベースである。Excelの表に似て見えるが、関係と制約まで設計できる点が違う。関係をたどってデータを結合でき、入れてよいデータの条件をDB側で守れる。Webアプリの土台として広く使われている。
  • 具体例：支援ステータス機能で、受講者、メンター、担当関係、支援ステータスをそれぞれテーブルにして関係でつなぐ。
  • つまずきやすい点：表計算ソフトと同じ感覚で考え、関係や制約の設計を後回しにしてしまう。
  • 関連語：テーブル（第10章）、正規化（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

スキーマ

  • 読み：スキーマ（schema）
  • 一言で言うと：データベースのテーブルやカラム、制約などの構造の定義。
  • くわしく：スキーマは、どんなテーブルがあり、どんなカラムや制約を持つかという、データの入れ物の設計である。アプリの機能が変わると、スキーマも変える必要が出る。スキーマが明確だと、保存できる形、API、テストの期待値がぶれにくくなる。実際のアプリでは、既存スキーマの命名や型に合わせて設計する。
  • 具体例：支援ステータスを保存するため、learner_support_statuses テーブルをスキーマに追加する。
  • つまずきやすい点：学習用ドラフトのスキーマと、スターターアプリの実スキーマを混同し、前提の違いを説明できない。
  • 関連語：DDL（第10章）、マイグレーション（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

テーブル

  • 読み：テーブル（table）
  • 一言で言うと：同じ種類の事実を集めて保存する場所。
  • くわしく：テーブルは、受講者なら受講者、メンターならメンターというように、同じ種類のデータを行として集める。何をテーブルにするかは設計判断である。後から取得、更新、参照する必要がある概念をテーブルにする。何でもテーブルにすると設計が大きくなり、保存すべき事実を保存しないと後で困る。
  • 具体例：受講者を learners、メンターを mentors、担当関係を mentor_assignments というテーブルで表せる。
  • つまずきやすい点：すべての概念をテーブルにしてしまい、整合性の確認が増えすぎる。
  • 関連語：行（第10章）、カラム（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

行

  • 読み：ぎょう（row／レコード）
  • 一言で言うと：テーブルに保存される1件のデータ。
  • くわしく：行は、テーブルの中の1件分のデータである。レコードとも呼ぶ。受講者テーブルなら、1人の受講者が1行になる。行を一意に見分けるために主キーを使う。現在値だけを持つ設計なら、受講者1人につき支援ステータスの行を1つだけ持つ。
  • 具体例：受講者「田中さん」の支援ステータスは、learner_support_statuses の1行として保存できる。
  • つまずきやすい点：1件のデータを「行」と呼ぶことに慣れず、列（カラム）と取り違える。
  • 関連語：カラム（第10章）、主キー（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

カラム

  • 読み：カラム（column／列）
  • 一言で言うと：一つの行に保存する一つの属性。
  • くわしく：カラムは、行の中の一つの属性である。列とも呼ぶ。カラム設計では名前だけでなく、意味、型、必須か任意か、入れてよい値、誰がいつ変えるかまで考える。型はデータの意味も伝える。IDは整数かUUIDか、日時は文字列かtimestampか、といった判断が後のAPIやテストに影響する。
  • 具体例：learner_support_statuses の status、note、updated_by、updated_at がカラムである。
  • つまずきやすい点：すべてを文字列カラムにして、状態、日時、IDの意味を失う。
  • 関連語：行（第10章）、NOT NULL（第10章）、NULL（第10章）
  • テキスト本文での登場箇所：第10章「カラムは、意味、型、NULL可否、制約で説明する」

NULL

  • 読み：ヌル／ナル（NULL）
  • 一言で言うと：値がない、または不明であることを表す特別な値。
  • くわしく：NULLは「値が入っていない」「分からない」という状態を表す。空文字 ''、数値の 0、支援ステータスの none とは意味が違う。任意のカラムをNULL可にする案も、常に文字列として扱うため空文字を既定にする案もある。どちらが正しいかではなく、意味と扱いをチームでそろえることが大切である。
  • 具体例：支援メモ note を任意にするなら、メモがない受講者の行で note をNULLにできる。
  • つまずきやすい点：NULL、空文字、none、0 を同じ意味として扱ってしまう。
  • 関連語：NOT NULL（第10章）、カラム（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

制約

  • 読み：せいやく（constraint）
  • 一言で言うと：入れてよいデータの条件をデータベース側で守る仕組み。
  • くわしく：制約は、データが矛盾しないようにDB側で守るルールである。面倒な付属機能ではなく、アプリケーションコードが間違えても最後にデータを守る防衛線になる。主キー、外部キー、NOT NULL、UNIQUE、CHECKなどがある。ただし、DB制約で守れることと、APIやアプリで確認すべきことは分けて考える。
  • 具体例：支援ステータスに入れてよい値をCHECK制約で固定し、定義外の値を拒否できる。
  • つまずきやすい点：外部キーがあるだけで、担当外更新の認可まで守れたと思ってしまう。
  • 関連語：主キー（第10章）、外部キー（第10章）、CHECK制約（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

主キー

  • 読み：しゅキー（primary key／PRIMARY KEY）
  • 一言で言うと：行を一意に識別する値。
  • くわしく：主キーは、テーブルの中で行を一人ずつ、一件ずつ見分けるための値である。業務上の番号や文字列をそのまま使う場合もあれば、DBで採番したIDを使う場合もある。後から意味が変わりにくく、同じ行を安定して指せることが大事である。複数のカラムを組み合わせた複合主キーにもできる。
  • 具体例：learners.id は受講者を見分ける主キーで、mentor_assignments は (mentor_id, learner_id) の複合主キーにできる。
  • つまずきやすい点：後から意味が変わる業務値を主キーにして、同じ行を安定して指せなくなる。
  • 関連語：外部キー（第10章）、UNIQUE（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

外部キー

  • 読み：がいぶキー（foreign key／FOREIGN KEY）
  • 一言で言うと：別のテーブルの行との関係を守る値。
  • くわしく：外部キーは、あるテーブルの行が別のテーブルの行を参照する関係を表す。参照先が存在することをDBに確認させるので、孤立したデータを防げる。たとえば、存在しない受講者IDに支援ステータスを付けようとすると拒否できる。ただし、参照先が存在することは守れても、業務上の認可まで自動では守れない。
  • 具体例：learner_support_statuses.learner_id を learners.id への外部キーにすると、存在する受講者にだけ支援ステータスを付けられる。
  • つまずきやすい点：updated_by の外部キーで存在するメンターは保証できても、そのメンターが担当者かまでは保証されない。
  • 関連語：参照整合性（第10章）、主キー（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

参照整合性

  • 読み：さんしょうせいごうせい（referential integrity）
  • 一言で言うと：存在しない相手を参照するデータを防ぐ性質。
  • くわしく：参照整合性は、外部キーなどによって、参照先が必ず存在することを保つ性質である。これがないと、存在しない受講者IDを指す支援ステータスのような、孤立したデータが生まれる。孤立データは画面には表示できても、後からJOINすると食い違いの原因になる。外部キーは参照整合性を守る代表的な仕組みである。
  • 具体例：支援ステータスの learner_id が必ず実在する受講者を指すことを、参照整合性として守る。
  • つまずきやすい点：参照整合性をアプリ任せにして外部キーを省き、孤立データに後から気づく。
  • 関連語：外部キー（第10章）、JOIN（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

NOT NULL

  • 読み：ノットヌル（NOT NULL）
  • 一言で言うと：そのカラムにNULLを入れられないようにする制約。
  • くわしく：NOT NULL制約は、必須の値を空にさせないための制約である。これを付けると、値を入れずに行を保存しようとしたとき拒否できる。必須かどうかは業務の意味から決める。なお、既存データがあるテーブルにNOT NULLカラムを追加するときは、初期値をどうするかを決めないと既存行で失敗する。
  • 具体例：支援ステータスの status や updated_at を必須にしたいなら、NOT NULLを付ける。
  • つまずきやすい点：既存データへの影響や初期値を考えずにNOT NULLカラムを追加して、移行で失敗する。
  • 関連語：NULL（第10章）、制約（第10章）、バックフィル（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

UNIQUE

  • 読み：ユニーク（UNIQUE／一意制約）
  • 一言で言うと：同じ値、または同じ値の組み合わせを重複させない制約。
  • くわしく：UNIQUE制約は、重複してはいけない値や組み合わせを守る。主キーと違い、必須でないカラムにも付けられる。重複登録を防ぎたい場面で使う。複数カラムの組み合わせに対しても付けられる。
  • 具体例：同じメンターと受講者の担当関係を二重登録しないように、(mentor_id, learner_id) をUNIQUE（または複合主キー）にできる。
  • つまずきやすい点：単一カラムだけにUNIQUEを付け、組み合わせの重複を防げていない。
  • 関連語：主キー（第10章）、制約（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

CHECK制約

  • 読み：チェックせいやく（CHECK constraint）
  • 一言で言うと：カラムに入れてよい値や条件をデータベース側で制限する制約。
  • くわしく：CHECK制約は、入れてよい値を条件で限定する制約である。許可する値のリストや、満たすべき条件を指定する。状態の候補値が少なく固定でよいなら、文字列カラムとCHECK制約で始められる。定義外の値を入れようとすると拒否されるので、設計で決めた状態だけを保てる。
  • 具体例：status IN ('none', 'needs_support', 'in_progress', 'resolved') で、支援ステータスの候補値だけを許可できる。
  • つまずきやすい点：成功するSQLだけ試して、定義外の値が拒否されることを確認しない。
  • 関連語：制約（第10章）、正規化（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

DDL

  • 読み：ディーディーエル（Data Definition Language）
  • 一言で言うと：テーブルや制約など、DBの構造を定義するSQL。
  • くわしく：DDLは、データの入れ物を作る系統のSQLである。テーブルの作成、カラムや制約の定義などが含まれる。データそのものを出し入れするDMLとは役割が違う。スキーマを変えるときはDDLを書くことになる。DBMSによって型や制約の書き方が変わる。
  • 具体例：CREATE TABLE learner_support_statuses (...) で支援ステータスのテーブルを定義するのがDDLである。
  • つまずきやすい点：DDLとDMLの区別があいまいで、構造変更とデータ操作を混ぜて考える。
  • 関連語：DML（第10章）、スキーマ（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

DML

  • 読み：ディーエムエル（Data Manipulation Language）
  • 一言で言うと：データの追加、更新、削除、取得を行うSQL。
  • くわしく：DMLは、テーブルの中のデータを操作する系統のSQLである。SELECT、INSERT、UPDATE、DELETEなどが含まれる。構造を定義するDDLとは別の役割を持つ。設計したテーブルでユースケースを満たせるかは、主にDMLで確認する。
  • 具体例：支援ステータスをINSERTやUPDATEで保存し、SELECTで担当受講者一覧を取得するのがDMLである。
  • つまずきやすい点：DDLとDMLの区別がつかず、どちらの確認をしているか説明できない。
  • 関連語：DDL（第10章）、SELECT（第10章）
  • テキスト本文での登場箇所：第10章「制約は、データを壊さないための設計である」

SELECT

  • 読み：セレクト（SELECT）
  • 一言で言うと：データベースからデータを取得するSQL。
  • くわしく：SELECTは、テーブルから条件に合うデータを取り出すSQLである。取得するカラムや、絞り込み条件、並び順を指定できる。設計確認では、ユースケースに必要なデータを取り出せるかをSELECTで見る。結果が空のときは、データがないのか条件が間違っているのかを切り分ける。
  • 具体例：特定のメンターの担当受講者と現在の支援ステータスを、SELECTで一覧として取得できる。
  • つまずきやすい点：成功するSELECTだけ書いて、制約違反が失敗することを確認しない。
  • 関連語：JOIN（第10章）、DML（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

JOIN

  • 読み：ジョイン（JOIN）
  • 一言で言うと：関係するテーブル同士を条件でつないで読む操作。
  • くわしく：JOINは、別々のテーブルを条件でつなげて、関係するデータをまとめて取得する操作である。RDBの強みである関係をたどる作業がJOINにあたる。担当関係や支援ステータスのように複数テーブルにまたがるデータを、一覧として取り出せる。つなぐ条件を間違えると結果がずれるので注意する。
  • 具体例：mentor_assignments、learners、learner_support_statuses をJOINして、担当受講者と現在ステータスを一覧にできる。
  • つまずきやすい点：JOIN条件の間違いで結果が空になり、データがないのか条件ミスか切り分けられない。
  • 関連語：LEFT JOIN（第10章）、SELECT（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

LEFT JOIN

  • 読み：レフトジョイン（LEFT JOIN）
  • 一言で言うと：左側のテーブルの行を残しつつ、右側に一致する行があれば結合する操作。
  • くわしく：LEFT JOINは、左のテーブルの行を必ず残し、右のテーブルに対応する行があればつなぐJOINである。対応する行がなければ、右側の値はNULLになる。まだ関連データがない行も一覧から落とさずに出したいときに使う。通常のJOINだと、片方に行がない場合に結果から消えてしまう。
  • 具体例：まだ支援ステータス行がない受講者も一覧に出すため、learner_support_statuses をLEFT JOINする。
  • つまずきやすい点：通常のJOINを使ってしまい、ステータス未設定の受講者が一覧から消える。
  • 関連語：JOIN（第10章）、COALESCE（第10章）、NULL（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

COALESCE

  • 読み：コアレス（COALESCE）
  • 一言で言うと：値がNULLの場合に、代わりの値を返す関数。
  • くわしく：COALESCEは、複数の値を順に見て、最初のNULLでない値を返すSQL関数である。NULLを画面用の既定値に置き換えたいときに使う。LEFT JOINでNULLになった項目を、表示しやすい値に変えるのに便利である。NULLそのものと、置き換えた値の意味の違いは押さえておく。
  • 具体例：支援ステータス行がない受講者を、COALESCE(status, 'none') で画面上は none として扱える。
  • つまずきやすい点：COALESCEで隠したNULLと、本来の none を同じものとして設計してしまう。
  • 関連語：NULL（第10章）、LEFT JOIN（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

プレースホルダー

  • 読み：プレースホルダー（placeholder）
  • 一言で言うと：SQLに後から値を安全に渡すための差し込み口。
  • くわしく：プレースホルダーは、SQLの中で値が入る場所を示す印である。アプリからは、ライブラリのパラメータ機能を使ってこの場所へ値を渡す。文字列連結でSQLを組み立てるのではなくプレースホルダーを使うと、入力値が命令として解釈される事故を防げる。これは後の章のSQLインジェクション対策にもつながる。
  • 具体例：担当受講者一覧のSQLで、メンターIDを WHERE mentor_id = ? のプレースホルダーで渡せる。
  • つまずきやすい点：DBMSにより記法が違い、SQLiteは ?、PostgreSQLのライブラリは $1 のように書く。
  • 関連語：SQL（第10章）、SQLインジェクション（第14章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

UPSERT

  • 読み：アップサート（upsert）
  • 一言で言うと：行がなければ追加し、既にあれば更新する操作の俗称。
  • くわしく：UPSERTは、update（更新）とinsert（追加）を合わせた呼び方である。同じキーの行があるかどうかを気にせず、なければ追加、あれば更新したいときに使う。現在値だけを持つ設計と相性がよい。決まった構文があるわけではなく、DBMSごとに書き方が違う。
  • 具体例：受講者ごとに現在ステータスを1行だけ持つので、更新はUPSERTで「なければ追加、あれば更新」とできる。
  • つまずきやすい点：UPSERTは俗称で標準構文がなく、DBMSによって書き方が違う点を見落とす。
  • 関連語：ON CONFLICT（第10章）、トランザクション（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

ON CONFLICT

  • 読み：オンコンフリクト（ON CONFLICT）
  • 一言で言うと：主キーやUNIQUE制約にぶつかったときの扱いを指定するUPSERT系の構文。
  • くわしく：ON CONFLICTは、主キーやUNIQUE制約に違反したときに、エラーにするのではなく更新などへ切り替えるための構文である。SQLiteやPostgreSQLで使えるが、書き方はDBMSによって違う。これを使うと、行があってもなくても1つのSQLでUPSERTを表現できる。履歴も持つ設計に変えるなら、更新と履歴追加をトランザクションでまとめる必要が出る。
  • 具体例：支援ステータスを ON CONFLICT (learner_id) DO UPDATE で、既存行があれば更新するように書ける。
  • つまずきやすい点：あるDBMSで動いたON CONFLICTの書き方が、別のDBMSでそのまま動くと思い込む。
  • 関連語：UPSERT（第10章）、UNIQUE（第10章）
  • テキスト本文での登場箇所：第10章「SQLで、ユースケースを満たせるか確認する」

正規化

  • 読み：せいきか（normalization）
  • 一言で言うと：同じ意味のデータを重複して持ち、不整合が起きることを減らす考え方。
  • くわしく：正規化は、同じデータを何カ所にもコピーして持たないようにする考え方である。重複があると、片方だけ更新されて食い違う危険がある。共通の値は1つのテーブルに置き、他のテーブルからはIDで参照する。一方で、何でも分ければよいわけではなく、今のユースケースに必要な範囲で考える。厳密な正規形を暗記する必要はない。
  • 具体例：受講者名は learners に置き、学習ログからは learner_id で参照すると、名前変更時の食い違いを防げる。
  • つまずきやすい点：正規化を意識しすぎて、固定値で十分な状態まで早すぎる別テーブルに分けてしまう。
  • 関連語：外部キー（第10章）、テーブル（第10章）
  • テキスト本文での登場箇所：第10章「正規化は、重複による不整合を減らす考え方である」

インデックス

  • 読み：インデックス（index）
  • 一言で言うと：検索や結合を助けるためのデータベース上の仕組み。
  • くわしく：インデックスは、よく使う検索条件や結合条件を速くするための仕組みである。本の索引のように、目的の行を早く見つける手助けをする。よく絞り込むカラムやJOINに使うカラムが候補になる。ただし、増やせばいつも良いわけではなく、更新コストや運用も増える。設計段階では候補として記録する程度でよい。
  • 具体例：メンターIDで担当受講者をよく探すなら、mentor_assignments.mentor_id がインデックス候補になる。
  • つまずきやすい点：速くなると思って付けすぎ、更新コストや運用の負担を見落とす。
  • 関連語：JOIN（第10章）、主キー（第10章）
  • テキスト本文での登場箇所：第10章「インデックス、トランザクション、マイグレーションの入口」

トランザクション

  • 読み：トランザクション（transaction）
  • 一言で言うと：複数の更新をひとまとまりとして成功または失敗させる仕組み。
  • くわしく：トランザクションは、いくつかの更新を「全部成功」か「全部やめる」のどちらかにする仕組みである。途中で片方だけ成功すると、データが中途半端な状態になって困る場面で使う。失敗したときは、行った変更を取り消して元に戻すことをロールバックと呼ぶ。現在値だけの単純な更新では意識しなくても、履歴も同時に更新する設計では必要になる。
  • 具体例：支援ステータスの現在値の更新と履歴行の追加を、トランザクションでまとめて成否をそろえる。
  • つまずきやすい点：片方だけ成功しても問題ないと考え、複数更新をトランザクションでまとめ忘れる。
  • 関連語：UPSERT（第10章）、マイグレーション（第10章）
  • テキスト本文での登場箇所：第10章「インデックス、トランザクション、マイグレーションの入口」

マイグレーション

  • 読み：マイグレーション（migration）
  • 一言で言うと：アプリの変更に合わせてDBスキーマを段階的に変更する作業。
  • くわしく：マイグレーションは、テーブル追加、カラム追加、制約追加などのスキーマ変更を、順を追って適用する作業である。既存データがある状態で構造を変えるので、初期値や既存行への影響を考える必要がある。問題があったときに変更を戻すロールバックの方針も決めておく。なお、第22章で扱うデータmigrationはデータの移し替えを指し、関連はするが焦点が違う。
  • 具体例：既存受講者に支援ステータスを追加するマイグレーションでは、初期値をどうするかを決める必要がある。
  • つまずきやすい点：既存データへの影響や初期値、ロールバック方針を決めずにスキーマを変えて、移行で詰まる。
  • 関連語：スキーマ（第10章）、バックフィル（第10章）
  • テキスト本文での登場箇所：第10章「インデックス、トランザクション、マイグレーションの入口」

バックフィル

  • 読み：バックフィル（backfill）
  • 一言で言うと：既存データに、新しく追加したカラムやテーブルの値を埋める作業。
  • くわしく：バックフィルは、スキーマ変更で増えたカラムや行に対し、既存データの分の値を後から埋める作業である。新しいNOT NULLカラムを足すと、既存行の値が決まっていないと困る。値を実際に埋めるのか、行がない場合に画面で既定値とみなすのか、といった移行方針を決める必要がある。マイグレーションとセットで考えることが多い。
  • 具体例：既存受講者全員に learner_support_statuses の none 行を作るか、行がなければ画面で none とみなすかを決める。
  • つまずきやすい点：バックフィル方針を決めずにNOT NULLカラムを追加し、既存行で制約違反になる。
  • 関連語：マイグレーション（第10章）、NOT NULL（第10章）
  • テキスト本文での登場箇所：第10章「インデックス、トランザクション、マイグレーションの入口」

DBMS

  • 読み：ディービーエムエス（Database Management System／データベース管理システム）
  • 一言で言うと：データの保存・検索・整合性維持を担うソフトウェア本体。SQLite・PostgreSQL・MySQLなど。
  • くわしく：RDBという考え方を実際に動かす製品がDBMSである。SQLの大枠は共通だが、型、日時の扱い、外部キーの設定、UPSERTの細部などは製品（方言）ごとに違う。学習では手軽なSQLiteを使い、本番ではPostgreSQLなどを使う、という差が出る。どのDBMSを使うかで、書けるSQLや設定が変わる。
  • 具体例：支援ステータス機能を手元のSQLiteで作り、本番をPostgreSQLにするなら、日時型やUPSERTの書き方が変わる点を確認してから移す。
  • つまずきやすい点：あるDBMSで動いたSQLが別のDBMSでもそのまま動くとは限らない。方言の違いを前提に確認する。
  • 関連語：RDB（第10章）、SQL（第10章）、マイグレーション（第10章）
  • テキスト本文での登場箇所：第10章「RDBは、テーブル、行、カラム、関係で考える」

中間テーブル

  • 読み：ちゅうかんテーブル（junction table／中間テーブル）
  • 一言で言うと：多対多の関係を、二つの外部キーを持つ別テーブルで表す仕組み。
  • くわしく：一人のメンターが複数の受講者を担当し、一人の受講者が複数のメンターから支援される、というように両側が「複数」になる関係は、片方のテーブルの外部キーだけでは表せない。そこで、両者のidを行として持つ専用のテーブルを挟む。これが中間テーブルである。
  • 具体例：メンターと受講者の担当関係を mentor_assignments（mentor_id と learner_id を持つ）という中間テーブルで表す。
  • つまずきやすい点：多対多を一つのカラムやカンマ区切りの文字列で表そうとすると、検索や整合性維持が難しくなる。専用テーブルにする。
  • 関連語：外部キー（第10章）、テーブル（第10章）、正規化（第10章）
  • テキスト本文での登場箇所：第10章「担当関係を、関係として保存する」

教材を検索