制約っていらなくね？ (114ﾚｽ)
上下前次1-新
10: 04/06/18 22:36 ID:??? AAS
>>8はMySQLユーザー
11(1): 04/06/19 07:38 ID:OHujBfWT(1) AAS
ただＤＢサーバーにアプリケーション機能を盛り込み過ぎるのもどぉーかなー
12: 04/06/19 10:10 ID:iDH3OAyt(1) AAS
>>11
その方が効率的だから、そうするのだろうが。
ｄｂをISAM（索引順編成ファイル）としか使ってないの？ｗ
13(3): [age] 04/06/19 16:32 ID:??? AAS
制約いらないよね。 いらないから使わなければいいだけのこと。
制約にひっかかるデータは事前にチェックして、どの部分がまずいのかを
使う側に明確に表示させたいからね。
そのままエラー内容表示させるのもダサいしね。
14(1): 04/06/19 18:26 ID:??? AAS
>>13
同意。
そもそも、制約に引っかかるようなデータを書き込むアプリは､作りがアレだとおもうが
15: 04/06/19 19:06 ID:??? AAS
>>13-14
ユニーク制約が、アプリ側でチェックできるんでつね？
重複チェックとは、別次元の問題だと思いまつが。。。
16: 04/06/19 20:25 ID:??? AAS
>>13
>使う側に明確に表示させたいからね。
>そのままエラー内容表示させるのもダサいしね。
制約違反はアプリにコールバックされるだろ
そこからエラーメッセージ出せばいいだけじゃん・・・
17: 04/06/19 22:40 ID:rF590MRN(1) AAS
>>１６
そうだよね〜
あるマスタにないものを別のテーブルに入れてはいけない場合を考えてみよう
プログラムがそれをやるとなると
マスタの中に存在するか調べてから入れないといけなくなる
制約使えばエラーが発生するのでそこでメッセージ受け取って
適切なエラーメッセージクライアントに返すだけ
ただ、最近では制約とか外部キーとか使わないものを推奨している雰囲気はある
18(1): 04/06/19 23:25 ID:??? AAS
まぁ、あれだ。データベース設計やる奴とアプリ組む奴
がちゃんと意思疎通できる程度の規模のアプリなら問題
ないわけだ。大規模システムやアプリ開発を外注に出す
場合なんか、コミュニケーション不足やバグで整合性が
保たれないデータを作られないようにに、設計者がガー
ドの意味で制約を張るのは当然だと思うよ。
19(1): 04/06/20 00:14 ID:??? AAS
>>18
そういう意味で制約を使うのなら納得。
でも、エラー処理をまかせるってのは、どうなんだろ。
いまどきは、そういうもんなの？
20: 04/06/20 00:39 ID:??? AAS
>>19
＞エラー処理を任せる
ここで言ってるエラー処理って
DBからエラー受け取って
エラーメッセージを振り分けて表示するだけのことじゃないかな？
実際、制約あればエラーあった時点でDB更新は無いわけだし
プログラミングは楽になる
21(2): 04/06/20 01:19 ID:??? AAS
本来データの重複や規定外の値が入るのを防ぐのは内部スキーマの担当で、それを
外部スキーマにやらせるならば、作成するすべての外部スキーマが
エラーチェック->●エラーなら=>エラー表示してやり直し ●OKなら=>保存=>次行ってみよー
という機構をもつ必要がある。そうすると外部スキーマの処理数が増えてバグを作りこむ
可能性も上がり、万一ひとつでもエラーチェックが甘い外部スキーマがあればそれのために
内部スキーマに整合性エラーが出かねない。
その点内部スキーマに持たせれば、外部スキーマは
保存->●エラーなら=>エラー表示してやり直し ●OKなら=>次行ってみよー
と、エラーチェックの結果を判断するだけでよくなって万一バグがあってもランタイムエラーで済む。
アプリの作成中は良くても、今後増改築があったときにすべてのテーブルに対してどのような
省6
22(1): 04/06/20 01:40 ID:??? AAS
>>21
俺もなるべくならDBにやらせたい派だな
だってNullはDBの機能で入れられないようにするくせに
外部キー制約はプログラミングで実装ていうのはおかしいよな
ただ、ひとつだけ
もし、「あ、このデータ消したいな」と思った場合に困るんだよな
そうした場合には制約ないほうがいいし
事実そうしているプロジェクトが多い
23: 04/06/20 01:56 ID:??? AAS
>22
つ[ ON DELETE CASCADE ]
つ[ ON DELETE SET NULL ]
24: 04/06/20 07:02 ID:??? AAS
今年のTE(DB)の試験では制約がいっぱい出ました
25: 04/06/29 02:09 ID:Pxx6PBqy(1) AAS
まあ、論理設計の意図を反映させる意味で制約はつけてるけど。
正直、ユニーク制約なんかはユニークインデックス付ける方がよくやる。
26(1): 04/07/08 13:48 ID:??? AAS
NOT NULLは大嫌い。
何度ユーザーに裏切られた事か。
業界標準コードがNULLの商品データとか
本番稼動後になってから平気で寄越したり。
そもそも画面から更新処理を行おうとした時点で
DB叩く前に入力チェックしなきゃいけないし。
未入力のフィールドにフォーカスあてたり
フィールドごとにエラー文言変えたり。
データはなるべく静的な物として捉えたいので
業務ロジックを盛り込む事は避けたいです。
省4
27: [ ] 04/07/08 22:36 ID:??? AAS
まぁシステムによりけりだね。
制約は断じて「業務ロジック」では無い。
でも設計がアレなシステムでは、制約が業務ロジック化してしまう。
28: 26 04/07/09 10:17 ID:??? AAS
制約自体に罪はない、設計がアレなだけだ、って事ですね。
今まで誤解してたよ、ごめんよ、制約。
全てアプリ側でコントロールすると
>21みたいな事にもなるしね。
これからは心を入れ替えて制約も活用してみます。
皆さん具体的にどうですか？
制約使って便利だーいやトラブったーとかあります？
外部キーとかってどうしても使う勇気が湧かないんですよ。
ただ新しい事やりたくないってだけなんですが。
29(8): 04/07/10 18:41 ID:+BBjcTFg(1) AAS
単にDBに値をチェックしてもらうだけならどうでもいいけど、関連レコードの自動削除みたいのはかなりいいと思うけどどうよ？
外部キーに ON DELETE CASCADE 付けとけば、親テーブルのレコードを削除するだけで紐付く子テーブルレコードも漏れなく削除できるよ。
ところで質問。
テーブルA とテーブルB があって、テーブルB はテーブルA の主キーを外部キーとして参照しています。
で、テーブルA のレコードに紐付くテーブルB が存在するかどうかを確認したいです。
できれば参照されている件数なんかも知ることができるといいです。
SELECT なりでも調べられますが、実は実際に扱おうとしているものは、テーブルA の主キーを外部キーとするテーブルがべらぼうに多くて、ちょっと大変です。
こんな感じになっちゃいます。
SELECT
TABLE_A.ID,
省8
上下前次1-新書関写板覧索設栞歴
あと 85 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.672s*