【恐怖】主キーがないテーブルみたことありますか？

データベースの制約を利用せずに、アプリケーションで事前チェックをするのは馬鹿げている、と言う人がいるけど
実際の UI を考えると、アプリケーションでの事前チェックは事実上必須だと思います。

・一意制約
アプリケーションでは、伝票番号などの主キーを入力して、すでに存在すれば
編集モード(編集後は update)、存在しなければ新規作成(編集後は insert) と
することも多いと思います。つまり、一意制約に頼らずにレコードの存在チェックはしている。

・NULL許可, 外部参照制約
アプリケーションでは、商品コードを入力したらその名称を表示します。
つまり、この時点で外部テーブルが参照できるか確認しているわけです。
そして、該当データが見つからなければアプリケーションとして再入力を促す。

つまり、使い勝手を考慮したアプリケーションでは、データ更新を試みる前に
ある程度のチェックを行うのは一般的だと思うわけです。

もちろん、アプリケーション以外の汎用的な操作ツールでデータ操作される可能性もあるので、
私は、ちゃんとデータベースの制約を設定していますけどね。

>252
DBの制約とアプリケーション上のチェックは基本的に層が違う。
一意制約の役目は存在チェックじゃないべさ。
外部参照制約に関しても同様。
データ層において、矛盾するデータが存在しないように縛るのが制約の役目。
制約に引っかかった場合に何をどうするかはビジネスロジック層の話。

一意制約 = 存在チェック ではないけれど、アプリケーションで存在チェックを
行って上手くハンドリングすることで、一意性が保たれるということ。

DB でできることを、わざわざアプリケーションでやる必要はない、という意見もあるけど、
「わざわざ」やっているわけではなくて、一般的な UI を考えたら、「おのずと」
アプリケーションでの事前チェックは必要になる。そして、アプリケーションによって
一意性は保たれる。一意制約違反が出てから、それをハンドリングするなんていう
アプリケーション実装は考えられない。

外部参照制約についてもそう。アプリケーションでディメンションにデータがあることを確認してから、
ファクトテーブルに更新する。これも「わざわざ」ではなく、画面にディメンションの内容を表示する
都合があるので、アプリケーションで参照確認を事前に行うのは当たり前。

なので、データベースの制約違反をアプリケーションでハンドリングする、
というのが私には違和感があります。私は制約違反はあくまでも例外系という
位置付けでエラーが発生すれば、その内容を直接エラーダイアログで表示、
確認後、アプリケーション終了、という手法をとっています。

主キー制約ｲﾗﾈって事？
何が言いたいのかﾜｶﾝﾈ

いや、制約は必要です。データ保証、セーフティネットとして。
ただ、制約違反(例外発生通知)を積極的に利用したビジネスロジックの実装なんて
現実的ではないと思っただけです。

大量一括更新処理においてなら珍しくも何とも無いし、データベース用のフレームワークで
DBからの制約違反通知を利用してUIを持つアプリ組む例を見たことがあるし、
結局の所、それで工数が削減できるとか保守性が上がるとかなら積極的に使えばいいし
そうでなければ使わなければいいだけの話でぁ

>257
そうやね。どんな状況でも DB まかせ、アプリまかせではいかんということで、
DB の制約は最後の砦、アプリはできる範囲で、一件ずつなら面倒見れば
いいし、一括登録ならアプリの判断は DB, NW 共に負担大だから DB に
お任せとかと使い分ければ DB や 他の資源にかかる負担も減るしレスポンスも
良くなってユーザも管理者もみんなﾆｺﾆｺだ。