DBアプリケーションの設計方針 (参照整合性、外部キーなどの制約はDDLで定義すべき？)

質問

標記の件でご意見を伺いたく投稿します。
データベースにおいて、参照整合性、外部キーなど、レコードの整合性を守るのに不可欠な要素が
いくつかありますが、これらをDDLで定義するのと、フロントエンドのアプリケーションで実装する
のと、どちらが望ましいでしょうか？

世間で普及している教本等では、DDLで定義することになっているようですが、この辺りをきちんと
作り込んだ経験がありません。理由は以下の通りです。

(1) 制約でガチガチに縛ってしまうと、テストデータの作成に難儀する。
→ Access の場合、アプリケーションの画面が影も形もない段階で、テーブルのデータシート
ビューから直接データを投入できるが、制約で縛るとこの手軽さが失われてしまう。
(トリガを書けば、データは投入できるが、何だか余分な作業が増えて損をしたような気がする)

(2) データの整合性は保証できるものの、制約に違反した場合のエラーメッセージがユーザー
フレンドリーではない。
↓
結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。
↓
DDLで制約を定義しても、アプリケーション実装の作業負担は軽くならない。

そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。
Accessの場合、ド素人でもデータベースを直接GUIから操作できるので、設計者の意図に反して
データの整合性が損なわれるリスクはありますが、総合的に見て、DDLで制約を定義するメリット
を私はあまり感じません。

一般的にはどうなのでしょうか？
専門家の皆様のご意見をお待ちしております。

初心者ですので、わかりやすくご指導頂けると幸いです。(笑)

回答No.4

noname#11722 · ベストアンサー

>そんな訳で、主キー、規定値以外の制約をDDLで実装した経験は殆どありません。

業務の種類によって対応はまちまちですが、
私も主キー、規定値、サイズくらいですかね。

>結局、アプリケーションで、エラーを事前に開始するか、またはエラーメッセージをユーザー
向けの文言に書き換える処理が必須となる。

これも同意です。
アプリのほうでメッセージ出して、なおかつ通常のメッセージボックスはダメという要求が多い。
結局作りこむことになるのが現状

なおかつ、現在個人情報保護法等もあり、
データフィールドを個別に暗号化処理するようにしてしまったので、
基本の制約は意味を成さなくなってしまいました、

暗号化込みのデータベースが出ればまた使うかもしれないですが・・・

なので、最近に限って言えばほとんど使っていません。

お礼

コメントありがとうございます。

やはり、どの案件でも、似たような苦労をされているのですね。
私の感覚が世間の常識と極端に乖離している訳ではないことがわかり、ほっとしました。

回答No.5

cse_ri2

No.3の回答の追加です。

質問の内容を読み違えていたようなので、追加で回答
します。

データの整合性を保つには、アプリケーションで行う
という意見に賛成です。
私も外部キーは、滅多なことでは作成しません。

アプリとインデックスの設計がしっかりしていれば、
ほぼ不要ですし、むしろ外部キーの更新に時間がかかる
ため、レスポンス面で不利となることがあるからです。

お礼

コメントありがとうございます。

私の感覚が世間の常識と極端に乖離している訳ではないことがわかり、ほっとしています。

補足

元投稿に若干の誤字がありましたので、この場をお借りして訂正します。

> トリガを書けば、データは投入できるが・・・
→ トリガ、またはストアド等を書けば、必要に応じてデータは投入できるが・・・

> アプリケーションで、エラーを事前に開始するか
→ アプリケーションで、エラーを事前に回避するか

本当に必要なら、外部キーや参照整合性制約を定義するのはやぶさかではないが、開発初期の段階でガチガチにするのも良し悪しだと思っています。
アプリケーションをある程度作り込んでから必要な制約を追加していくのもありなのではないかと・・・。

回答No.3

cse_ri2

＞Access限定の話ではなく、一般論としてのRDBのある
＞べき姿です。

一般的なRDB(Oracle,SQLServerなど)でしたら、なおさら
DDLでテーブル定義すべきです。

DDLが書けなくても、PowerBuilderなどのツールを使えば
GUIでテーブル作成ができます。

しかし、GUIでテーブルを作った場合、実際に発行される
SQLは、ツールが自動生成したものが使われます。
このようなSQLでは、パフォーマンスの面で最適な設計と
ならなくなってしまいます。

OracleやSQL-Serverで一度でもパフォーマンスチューニング
を体験すればわかるのですが、RDBで最適な結果を出す
には、単にインデックスの張り方だけではなく、RDBが
管理するデータファイルのどの領域を使うかにまで踏み
込む必要があります。

上記の内容は、RDBの管理者になって、性能問題で一度
は苦しまないと、実感できないかもしれません。
これからスキルをつけて、頑張ってください。

補足

コメントありがとうございます。
実は、大規模なデータベース、ミッションクリティカル (この言葉を安易に多発するのもどうかと思いますが) な案件の経験がなく、比較的小規模なデータベースしか経験がありません。
性能上の悩みは、DB設計より、アプリケーションの作り (→ 他人の作り損ないの尻拭い) に起因することのほうが私の経験では多かったようです。

回答No.2

skikichi

Accessでの話しでしょうか？
システムの高い信頼性を要求したり、大規模なネットワーク管理、ユーザー管理をするのでしたら、そもそもAccessを使用しませんよね！？

小規模で高い信頼性を確保するのでしたら、Accessにもデータ整合性を確保する方法としてトランザクションが存在しますよね。
トランザクション管理やLockEditではダメですか？

補足

コメントありがとうございます。
Access限定の話ではなく、一般論としてのRDBのあるべき姿です。

回答No.1

cse_ri2

プロなら、きちんとＥＲ図を書き、設計書もおこして、
テーブル作成もDDLで行います。

自分ひとりでシステムを起こすなら、そこまで必要ない
かもしれませんが、他人を使うのであれば、きちんと
した仕様書は必須です。

補足

コメントありがとうございます。

お訊きしたいのは設計ドキュメントのあり方ではなく、実装レベルでの方針です。