- ベストアンサー
参照整合性制約を実装するのは当たり前？
- 参照整合性制約は、実装するのが当たり前と思ってましたが、そうでもないのでしょうか？
- 最近、関わっているシステムは、Ｏｒａｃｌｅですが、参照整合性制約は実装されおらず、全てアプリケーションが頑張っています。
- なんで参照整合性制約を実装しないのか、ＤＢ担当でないので分からないのですが、私は実装しないＲＤＢはクリープを入れないコーヒーのようなものではないかと思うのです。
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
これには賛否両論があるので一概にどちらがよいとは言い切れません。私はＤＢの物理設計コンサルタントとして客先でＤＢの物理設計を担当したことがありますが、その際には開発環境では参照制約を設定し、本番環境では競ってしないということに決まりました。 制約を付けるということは、ＤＭＬ文が発生するたびに整合性のチェックされることになるので (Oracle にはチェックするタイミングを設定するオプションもあるが)、性能の劣化の原因にもなり得ます。 特に、参照制約の場合には他のテーブルにまで検索しに行く必要があるため、どうしても他の制約に比べてオーバーヘッドが大きくなってしまいがちです。 そのために付けないことも多いですが、だからといって、参照制約を設定できないようなＤＢ設計をすることは望ましいとは言えません。 あと、既にお気づきのようですが、参照制約を設定したからといってアプリケーション側のハンドリングが不要になるわけでもありません。まさか、ユーザとのインターフェースに ORA-XXX と表示されるようなアプリケーション設計はされないでしょうから。
その他の回答 (2)
- kazuho_goo
- ベストアンサー率56% (34/60)
>専門家の方、経験豊富な方、ご意見お待ちしております。 これには該当しませんが... 私も参照整合性制約は実装するほうが望ましいと思います。ただし、画面などを使用したアプリの場合、違反レコードに対するエラーメッセージはOracleそのままよりユーザーに分かり易いメッセージにしたり、強制ロールバックよりエラーデータ保存処理するなど、適切なエラー処理は必要になってくると思います。となると、プロジェクトリーダーは「画面側で整合性チェックと等価の機能を実装しているから管理面、工数を考えてなくしちゃえ」と参照整合性制約を実装しないという考えの方もいらっしゃると思います。
お礼
回答ありがとうございます。 確かに制約をＤＢで実装していても、けっきょくアプリでハンドリングは必要ですよね。 だったら最初からＤＢでは制約しなくていいか、ということにもなるかもしれませんね。
- ese_ee
- ベストアンサー率48% (68/139)
僕はブラックが好きです（笑 というのはさておき） 確かにうまくはまれば便利なので、理想としてはそうしたいですが、 参照整合性制約って、問答無用／厳格に適用されてしまうので、 データメンテのときなどのイレギュラーな処理や仕様変更の際に妙に不便だったりすることがあります。 また、そういう制約が破綻するような仕様変更があったときに、 制約をはずして、自前のチェックロジックをあちこちに実装しないとならなくなるので、 だったら最初から自前でチェックしとけばって感覚でしょうか。
お礼
回答ありがとうございます。 > そういう制約が破綻するような仕様変更があったときに、 > 制約をはずして、自前のチェックロジックをあちこちに実装しないとならなくなる なるほど、そういうことは考えてみませんでした。 いったん実装した制約を外すのはかなり怖いですね。 そこまで見越して、実装の有無を考えることもあり得る、ということですね。
![その他([技術者向] コンピューター) イメージ](https://gazo.okwave.jp/okwave/spn/images/related_qa/c205_3_thumbnail_img_sm.png)
お礼
> 開発環境では参照制約を設定し、本番環境では競ってしな なるほど！そういう方法もあるのですね。 > 参照制約を設定できないようなＤＢ設計をすることは望ましいとは言えません。 ですよね！ つまり、設計上は（当然のことながら）参照整合性を保証するような設計（アプリも）を行い、 開発環境では念のため参照制約を実装しておいて、思わぬアプリのバグなどを見つけるのに役立てる、と。 本番では、性能を睨みつつ実装するかどうかを考えても良い訳ですね。 かなり、心のモヤモヤが晴れたようです。 ありがとうございます！