プログラムとRDB上の外部キー設定について

Question

RDBって基本的に、リレーションを張る前提だとは思いますが、
プログラム上（特にORM機能を持つフレームワーク）でのリレーション設定をするだけで
それっぽい動きができることと、下手にリレーションを張ると複数テーブルに対して更新や削除を実施する際、
手間が増えるため、RDB上はリレーションを張らないように教えらてきました。

　RDB上でリレーション設定をしているとDB管理ツール（phpMyAdmin等）で見たとき、
リレーション適用後の表示を確認できるので便利なのですが、RDB上ではリレーション設定をしないのは、
一般的なのでしょうか？

Answer 1

下手にリレーションを張ると複数テーブルに対して更新や削除を実施する際、手間が増えるため、RDB上はリレーションを張らないように教えらてきました。

リレーションは良いんですけど、参照整合性は順序などの制約が絡んでくることはあります。
外部からのデータ投入などで、一旦制約を外してからデータ投入し、再度設定するとか。

RDB上でリレーション設定をしているとDB管理ツール（phpMyAdmin等）で見たとき、リレーション適用後の表示を確認できるので便利なのですが

単純なリレーションなら良いですけど、そうでない場合はツールで表せないばあいとかありますので、あまり精度は求めない方が良いと思います。

Comments

[uekky]

> リレーションは良いんですけど、参照整合性は順序などの制約が絡んでくることはあります。
> 外部からのデータ投入などで、一旦制約を外してからデータ投入し、再度設定するとか。

そうなんですよね。シーディング時に参照整合性の制約でエラーになるので、
シーディングの順序の整合性をとる方法を調べてみようと思います。

> ツールで表せないばあいとかあります

ツールの件は、おまけレベルで考えようと思います。

回答ありがとうございました。

Answer 2

RDB上ではリレーション設定をしないのは、一般的なのでしょうか？

一般的ではありません。
余程の事情が無い限りは、バッドノウハウと言い切ってしまえると思います。

下手にリレーションを張ると複数テーブルに対して更新や削除を実施する際、手間が増えるため、RDB上はリレーションを張らないように教えらてきました。

これは一般的には手間が増えるというデメリットでは無く、
RDBMSの制約によって異常なデータが発生することが確実に防止され、適正な値のみが存在することを前提に出来るというメリットになります。

おそらくそう教えた人は

• ORMやフレームワークで正しくリレーションを扱う事が出来ない、部品化出来ない
• アプリケーションを開発する前にDB設計を行う事が出来ない（コーディングしながらDB設計をするので、途中でDB定義が変わると手間が大きい）
• アプリケーション仕様がコロコロと変わり、それがデータモデリングまで影響する様なまずい開発/運用体制である
• そもそもDB設計をレビューする、管理するという概念を知らない

などの理由から、バッドノウハウを正しいものと信じているんじゃないでしょうか。

RDB上でリレーション設定をしているとDB管理ツール（phpMyAdmin等）で見たとき、
リレーション適用後の表示を確認できるので便利なのですが、

phpMyAdminだと「あればちょっと便利」くらいですが、
一般的には、DB定義から（MySQLWorkbenchなどER図を使うことが多いです）DB設計のレビュー/管理を実施するため、アプリケーションのソースまで見ないとデータモデルが把握出来ない状態というのはかなり不便な状態になります。

---

パフォーマンスについてはケースバイケースですが、外部キーが存在しないことで性能が極端に悪化する場合もあります。

中間テーブルに外部キーを設定しない場合のLaravelにおける性能劣化を検証する

Comments

[gentaro]

回答しようかと思ったけどこの回答に100%同意でした。

質問者と同様の事を言われ、その通り開発されてた製品を担当した経験があるけど、そのプロダクトは結果的にデータ不整合を起こしまくり、復旧がメチャクチャ大変で、開発時のメリット（とやら）よりもリリース後の損害の方が完全に、圧倒的に、とてつもなく大きかったですねぇ…。しかも影響が長期に渡るし。「この世の地獄ってのはこうやって作るんだな」と思いました。

敢えてリレーションを張らずにアプリ側で不整合を防ぐスタンスのプロジェクトで成功した、という趣旨の記事も昔何かで読んだ事はあるけど、そんなもんは仮に上手くいったとしてもレアケース中のレアケースで、そんな事やるプロジェクトは全員プロフェッショナルか全員バカのどっちかなんだろうと思います。

[uekky]

教えられたやり方だと、ER図をレビューしているにも関わらず、
ER図からDBのスキーマを生成後、
外部キーを削除するというER図と実DB間で乖離させる謎の工程が発生することと、
ソースを網羅しないとテーブル間の関係性が網羅できないときがあり、
懐疑的でした。

ご回答内容で腑に落ちたため、
こちらをベストアンサーに選択させていただきました。

ご回答ありがとうございました。

[tanat]

> gentaroさん
似たような話はたまに見かけるので、DBの基礎的な学習をせずに機能豊富なORMを使ってしまうと嵌まりがちな罠なのかもしれませんね。

一方で、どんな高機能なORMでもRDBMSの機能を完全に再現するようなスタンスでは無いので、誰もカバーしない（本来はRDBMSがカバーする）部分が発生して大変なことになるのは当然ですよね・・・

> 敢えてリレーションを張らずにアプリ側で不整合を防ぐスタンスのプロジェクトで成功した、という趣旨の記事も昔何かで読んだ事はあるけど、

高速でデータ定義が柔軟なNoSQLを使いつつ、RDBMSのいいところをORMで疑似的に提供する（役割としてはORMでは無いですが）
とかならそれなりに例がありそうな気はしますが、RDBMSでうまくいくのは本当にレアケースか、モックをでっち上げる時くらいでしょうね。

[tanat]

> uekkyさん
それは何というか、大変ですね。

考えられる理由としては、
最初の方でそういうポリシーにしてしまったがために、すでにデータ不整合がそこら中で起きていて修正できない→追加部分にだけ別ポリシーを適用すると全体としての整合性や一貫性が崩れるので仕方なく突き進んでいる　みたいな状況も想像できますが、なんにせよ真っ当な開発手法とは外れてしまっているのは確実だと思います。

Answer 3

下手にリレーションを張ると複数テーブルに対して更新や削除を実施する際、
手間が増えるため

正しく設定すれば手間は減らせることもあります。ON DELETE CASCADEとすれば、親テーブルのレコードを削除する時に子テーブルのレコードを道連れにすることができます。

Comments

[maisumakun]

> RDB上ではリレーション設定をしないのは、
一般的なのでしょうか？

性能やDBの機能性など、実現できない事情がある場合を除けば、基本的には「かけるべき」と考えます。関連しない値が混入した場合のハンドリングという余計なものを考慮しなくて済むのは大きなメリットです。

[uekky]

> 基本的には「かけるべき」と考えます

親子道連れ削除は、おっしゃる通り有用だと思いますので、
今後活用していくようにします。

ご回答ありがとうございました。