みなさんは「外部キー制約が一つもないDB」を見たことがありますか？
私は「Web系」や「SaaS」「モダンなアプリ」でしか開発経験がなかったSEです。
転職して初めて「日本のレガシー基幹システム」の現場に入り、
その“あまりにも違う常識”に驚かされた体験を記事にまとめます。
モダンなDB設計の“セオリー”
- テーブルを設計したら、PK（主キー）・FK（外部キー）を必ず定義
- リレーション＝DB構造で保証されている安心感
- DDL（CREATE TABLE文）やER図も「FK制約」を当たり前のように持っている
例）テーブル定義での外部キー指定
CREATE TABLE orders (
order_id NUMBER PRIMARY KEY,
customer_id NUMBER,
CONSTRAINT fk_orders_customers
FOREIGN KEY (customer_id)
REFERENCES customers(customer_id)
);
現場で出会った“想定外”の世界
- テーブル定義を見てみると外部キー制約が一つも無い…！？
- 設計書（Excel）やER図にリレーション線すら無い
- 担当者「JOINでつなげばいいんです」「アプリ側で運用してますよ」
- 「えっ、それで本当にデータの一貫性大丈夫なの？」と戸惑う日々
SQLでしか“つながっていない”DB
現場でよく見るSQLの実例：
SELECT
A.受注番号,
B.受注行番号,
...
FROM
受注伝票データ A
LEFT OUTER JOIN 受注明細データ B
ON A.受注番号 = B.受注番号
WHERE
...
- JOIN句でリレーションを“都度つなぐ”だけ
- DBは「A.受注番号」と「B.受注番号」の整合性を何も保証してくれない
- データ登録・移行・削除時もアプリのロジックやバッチで手作業チェック
なぜこうなった？歴史と現場のリアル
- 「大量データをバッチで一気に処理したいから」
- 「外部キー制約があるとデータ移行や一括削除が面倒」
- 「現場の都合で、過去に“制約が邪魔”になったことが何度も」
- 「設計書やSQLで“人間がリレーション”を守るという文化」
何が困る？ギャップとリスク
- “多：多”のJOINで想定外の重複・膨張データ
- 親が無い子レコードが平気で作れてしまう
- 集計ミスや納品ミス、データ不整合が起きてもDBは止めてくれない
- 設計書・バッチ・属人運用頼みで継承ミス・運用事故が絶えない
モダン設計との違い・どうすればいい？
-
物理的な外部キー制約を張るのが王道！
→ DBが“守ってくれる安心感” -
どうしても制約が張れない現場では…
→ 移行前検証スクリプト、設計書ルール、開発時のレビューを徹底
まとめ・これから現場に入る人へ
- “SQLのJOINだけではリレーションにならない”
- DB設計＝制約も一緒に設計するのがベストプラクティス
- レガシー現場に出会ったら、「なんでこうなっているのか？」を担当者にしつこく聞いてみよう
- 自分が何を“常識”だと思っているのか、一度棚卸ししてみるのも大事！
おわりに
皆さんも、レガシーな現場で“知らない常識”に出会ったことがあれば、ぜひコメントで教えてください！