制約っていらなくね？ (114ﾚｽ)
制約っていらなくね？ http://mevius.5ch.net/test/read.cgi/db/1087483786/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
65: NAME IS NULL [] 2005/07/29(金) 13:13:32 ID:ug+wSNY+ >>63-64 直接引用じゃなく、要点絞って記述するね。 >アプリで実装するほうが判りやすくて楽 １つのテーブルに対する処理が10個も20個もあるアプリで、 全ての処理が正しく動作することを補償するのは楽でしょうか？ NOT NULLの制約もないDBとか最悪ですよ。 >制約をつけると再実装 逆です、制約がまず実装でアプリ側が再実装。 アプリ作るのに、DB設計もせずに始めるのでしょうか？ で、トリガーと制約は別問題。 論理的制約をトリガーで実装するってのはあるけど。 主キーもない、NULL制約もないDBなんて、DB使わないでファイルに書けばいいじゃん。ｗ http://mevius.5ch.net/test/read.cgi/db/1087483786/65
68: NAME IS NULL [] 2005/07/29(金) 14:33:29 ID:ug+wSNY+ >>67 > 業務要件としてNOT NULLなものって > アプリ側で入力チェックしますよね。 > アプリ側の実装はどうしても必要になっちゃう。 > で、そういうチェックはユーティリティクラスとかヴァリデーターとか > そんな風に共通化する訳です。 アプリでの入力チェックとNotNull制約では、後者のほうが広い意味です。 入力チェックしても防げないバグデータでも制約で防げます。 それに、アプリを通さないDBテーブル同士でのデータ登録とか更新もありますし。 > 1つのテーブルに対して10個も20個も処理があったとして > アプリ側の設計で実装は1つにまとめられると思います。 クラスなど実装が１つにまとめられることと、SQLの種類が複数になることは別問題ですよ。 その各パターン毎の更新などに対して、不慮の事故などをどのようの防ぐのですか？ 全てのパターンを１つの汎用SQLで行った場合にしても、それらのパターン毎の試験は必要です。 > 概念設計において業務要件を反映した制約を > そのまま実装としてDBに入れるか、 > アプリでやるかって所だと。 DBの責務としての制約はDBでやるべきだし、アプリの制約はアプリでやるべき。 それに、DBが常にアプリを通して更新されるとは限らないし。 メンテとか、後の修正や他システムとの連携などで、そのアプリに対する制約を相手に望めますか？ > うーん、書いてて自分の強い優位性が見出せぬ。 > 過去の振り返りにしかなってない・・・わはは。 だって、便利な機能を否定して茨の道を歩んでるから。 両方制約すればいいんですよ、DBとアプリの独立性を高めて考えて、それぞれの責務を課す。 DBは自分の入れられたくないデータを制約し、アプリは他に出せないデータは出さない。 http://mevius.5ch.net/test/read.cgi/db/1087483786/68
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.649s*