制約っていらなくね？
あ、煽ってる訳じゃないです。
制約に対する偏見なのかなあって
ちょっと思ってきては居るんで
背中押してもらいたいというのが本音。
>61の連鎖削除・更新も
業務要件だからアプリで実装したいんですよねぇ。
トリガーもそうなんですが。
ださいのかなー。
あっ、でもレスポンス向上の一手に使えるってのは
いいっすね！そういうかわいい悪どさは好きです。
制約に対する偏見なのかなあって
ちょっと思ってきては居るんで
背中押してもらいたいというのが本音。
>61の連鎖削除・更新も
業務要件だからアプリで実装したいんですよねぇ。
トリガーもそうなんですが。
ださいのかなー。
あっ、でもレスポンス向上の一手に使えるってのは
いいっすね！そういうかわいい悪どさは好きです。
65 ：NAME IS NULL：2005/07/29(金) 13:13:32 ID:ug+wSNY+
>>63-64
直接引用じゃなく、要点絞って記述するね。
>アプリで実装するほうが判りやすくて楽
１つのテーブルに対する処理が10個も20個もあるアプリで、
全ての処理が正しく動作することを補償するのは楽でしょうか？
NOT NULLの制約もないDBとか最悪ですよ。
>制約をつけると再実装
逆です、制約がまず実装でアプリ側が再実装。
アプリ作るのに、DB設計もせずに始めるのでしょうか？
で、トリガーと制約は別問題。
論理的制約をトリガーで実装するってのはあるけど。
主キーもない、NULL制約もないDBなんて、DB使わないでファイルに書けばいいじゃん。ｗ
直接引用じゃなく、要点絞って記述するね。
>アプリで実装するほうが判りやすくて楽
１つのテーブルに対する処理が10個も20個もあるアプリで、
全ての処理が正しく動作することを補償するのは楽でしょうか？
NOT NULLの制約もないDBとか最悪ですよ。
>制約をつけると再実装
逆です、制約がまず実装でアプリ側が再実装。
アプリ作るのに、DB設計もせずに始めるのでしょうか？
で、トリガーと制約は別問題。
論理的制約をトリガーで実装するってのはあるけど。
主キーもない、NULL制約もないDBなんて、DB使わないでファイルに書けばいいじゃん。ｗ
66 ：NAME IS NULL：2005/07/29(金) 13:48:36 ID:ZZgow+OE
火と大杉で見れないよ
>>65
まず具体的にNOT NULL制約に話なんですが、
業務要件としてNOT NULLなものって
アプリ側で入力チェックしますよね。
アプリ側の実装はどうしても必要になっちゃう。
で、そういうチェックはユーティリティクラスとかヴァリデーターとか
そんな風に共通化する訳です。
1つのテーブルに対して10個も20個も処理があったとして
アプリ側の設計で実装は1つにまとめられると思います。
で、ままあるんですが、当初NOT NULLだと思ってたのが
実はNULLもあるんだよーなんて突然お客様に言われた時に
アプリ側で仕様が把握し切れればいいんじゃないかなと思っちゃう。
>アプリ作るのに、DB設計もせずに始めるのでしょうか？
DB設計は事前にしますよ。ER図も書きます。
でもそれは論理設計と言うか概念設計です。
実際にDBを構える時はまた考え直します。
概念設計において業務要件を反映した制約を
そのまま実装としてDBに入れるか、
アプリでやるかって所だと。
ちょっと話はずれますが、
概念設計と実装で構成が違うのは当たり前にやってます。
特に識別子の考え方。概念では識別子は業務に沿って考えます。
だから「注文番号 + 行番」なんて複合キーもガンガン使います。
でも実装では、「注文明細ID」をキーにします。
勿論、一意制約とインデックスは「注文番号 + 行番」につけますけど。
だから、参照整合やNOT NULLに関しても
実装ではぶいてアプリで実装ってのにあまり抵抗がないのかも
知れません。
うーん、書いてて自分の強い優位性が見出せぬ。
過去の振り返りにしかなってない・・・わはは。
レス有難う御座います。長文失敬でした。
まず具体的にNOT NULL制約に話なんですが、
業務要件としてNOT NULLなものって
アプリ側で入力チェックしますよね。
アプリ側の実装はどうしても必要になっちゃう。
で、そういうチェックはユーティリティクラスとかヴァリデーターとか
そんな風に共通化する訳です。
1つのテーブルに対して10個も20個も処理があったとして
アプリ側の設計で実装は1つにまとめられると思います。
で、ままあるんですが、当初NOT NULLだと思ってたのが
実はNULLもあるんだよーなんて突然お客様に言われた時に
アプリ側で仕様が把握し切れればいいんじゃないかなと思っちゃう。
>アプリ作るのに、DB設計もせずに始めるのでしょうか？
DB設計は事前にしますよ。ER図も書きます。
でもそれは論理設計と言うか概念設計です。
実際にDBを構える時はまた考え直します。
概念設計において業務要件を反映した制約を
そのまま実装としてDBに入れるか、
アプリでやるかって所だと。
ちょっと話はずれますが、
概念設計と実装で構成が違うのは当たり前にやってます。
特に識別子の考え方。概念では識別子は業務に沿って考えます。
だから「注文番号 + 行番」なんて複合キーもガンガン使います。
でも実装では、「注文明細ID」をキーにします。
勿論、一意制約とインデックスは「注文番号 + 行番」につけますけど。
だから、参照整合やNOT NULLに関しても
実装ではぶいてアプリで実装ってのにあまり抵抗がないのかも
知れません。
うーん、書いてて自分の強い優位性が見出せぬ。
過去の振り返りにしかなってない・・・わはは。
レス有難う御座います。長文失敬でした。
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は自分の入れられたくないデータを制約し、アプリは他に出せないデータは出さない。
> 業務要件としてNOT NULLなものって
> アプリ側で入力チェックしますよね。
> アプリ側の実装はどうしても必要になっちゃう。
> で、そういうチェックはユーティリティクラスとかヴァリデーターとか
> そんな風に共通化する訳です。
アプリでの入力チェックとNotNull制約では、後者のほうが広い意味です。
入力チェックしても防げないバグデータでも制約で防げます。
それに、アプリを通さないDBテーブル同士でのデータ登録とか更新もありますし。
> 1つのテーブルに対して10個も20個も処理があったとして
> アプリ側の設計で実装は1つにまとめられると思います。
クラスなど実装が１つにまとめられることと、SQLの種類が複数になることは別問題ですよ。
その各パターン毎の更新などに対して、不慮の事故などをどのようの防ぐのですか？
全てのパターンを１つの汎用SQLで行った場合にしても、それらのパターン毎の試験は必要です。
> 概念設計において業務要件を反映した制約を
> そのまま実装としてDBに入れるか、
> アプリでやるかって所だと。
DBの責務としての制約はDBでやるべきだし、アプリの制約はアプリでやるべき。
それに、DBが常にアプリを通して更新されるとは限らないし。
メンテとか、後の修正や他システムとの連携などで、そのアプリに対する制約を相手に望めますか？
> うーん、書いてて自分の強い優位性が見出せぬ。
> 過去の振り返りにしかなってない・・・わはは。
だって、便利な機能を否定して茨の道を歩んでるから。
両方制約すればいいんですよ、DBとアプリの独立性を高めて考えて、それぞれの責務を課す。
DBは自分の入れられたくないデータを制約し、アプリは他に出せないデータは出さない。
>>68
うーむ、茨の道、耳が痛いです。
やっぱりやった事ないから恐いってだけなんでしょうかね。
有難う御座います。
確かに、アプリを経由しないデータ連携などではお手上げですね。
最初からそんな要件なければいいですが
案件ごとに制約の実装方法がDB or アプリで
バラバラになっちゃうのも気持ち悪いですし
ポリシーとして最初から統一しちゃう方が、確かに安心。
あと、DBからの制約のエラーと
アプリでのエラーメッセージのマッピングで
困った事とかないですか？
DBからのエラーコードじゃ判りきらんよ、とか。
それも気になる所なのです。
柔軟にメッセージを対応させたきゃそれこそアプリの責務で、
アプリ側でチェックすれって所でしょうか。
うーむ、茨の道、耳が痛いです。
やっぱりやった事ないから恐いってだけなんでしょうかね。
有難う御座います。
確かに、アプリを経由しないデータ連携などではお手上げですね。
最初からそんな要件なければいいですが
案件ごとに制約の実装方法がDB or アプリで
バラバラになっちゃうのも気持ち悪いですし
ポリシーとして最初から統一しちゃう方が、確かに安心。
あと、DBからの制約のエラーと
アプリでのエラーメッセージのマッピングで
困った事とかないですか？
DBからのエラーコードじゃ判りきらんよ、とか。
それも気になる所なのです。
柔軟にメッセージを対応させたきゃそれこそアプリの責務で、
アプリ側でチェックすれって所でしょうか。
70 ：NAME IS NULL：2005/07/29(金) 15:52:26 ID:6uLcICyZ
DBから見たら制約を課すことまでが責務であって、その結果を返すだけだよ。
そのエラーをアプリがどう料理するかはアプリの実装の問題。
特定のエラーコードに意味を求める（キー重複など）場合はそのコードで分岐して処理すればいいし。
NULL制約違反ってのはあまり出したくはないよね。
やっぱ、アプリで事前チェックして、そもそもINSERTなどを投げないようにしたい。
Oracleとかだと、どのカラムで何のエラーってメッセージはもらえるけど、あくまで文字列情報だし、
貴方が悩むところはなんとなくは判ります。
そもそもとして、DBに制約をつけるのってそんなに大変か？ｗ
Check制約にしても、そんなに手間じゃないでしょ。
そのエラーをアプリがどう料理するかはアプリの実装の問題。
特定のエラーコードに意味を求める（キー重複など）場合はそのコードで分岐して処理すればいいし。
NULL制約違反ってのはあまり出したくはないよね。
やっぱ、アプリで事前チェックして、そもそもINSERTなどを投げないようにしたい。
Oracleとかだと、どのカラムで何のエラーってメッセージはもらえるけど、あくまで文字列情報だし、
貴方が悩むところはなんとなくは判ります。
そもそもとして、DBに制約をつけるのってそんなに大変か？ｗ
Check制約にしても、そんなに手間じゃないでしょ。
おっしゃる通り、別に大変でもないですよね。わはは。
飛ぶのが恐いわけじゃない、落ちていくのが恐いんだ
by 寺山修司
って心境です。
派手にバグを出してデータパッチわんさか当てなきゃーとか
なった時に、参照整合とかで苦労しないかなーとか
勝手に妄想してるのです。
次は飛んでみるかな。
飛ぶのが恐いわけじゃない、落ちていくのが恐いんだ
by 寺山修司
って心境です。
派手にバグを出してデータパッチわんさか当てなきゃーとか
なった時に、参照整合とかで苦労しないかなーとか
勝手に妄想してるのです。
次は飛んでみるかな。
72 ：NAME IS NULL：2005/07/29(金) 16:21:06 ID:6uLcICyZ
>>71
想定してる場面が発生する原因は・・・。
1）システム分析が甘く、DB設計が間違っている為、実情に合わない制約をDBに課した
2）そもそもの業務がフレキシブル（ｗ、なので、その時点での制約が邪魔になる。
のどちらかだと思うが。
前者であれば技量を磨くしかないし、後者はそもそも制約を付与する設計がやっぱり間違っているともいえる。
制約って基本的にはきつく課しておいて、緩めるときに本当に緩める理由があるか考えるほうが安全だよ。
想定してる場面が発生する原因は・・・。
1）システム分析が甘く、DB設計が間違っている為、実情に合わない制約をDBに課した
2）そもそもの業務がフレキシブル（ｗ、なので、その時点での制約が邪魔になる。
のどちらかだと思うが。
前者であれば技量を磨くしかないし、後者はそもそも制約を付与する設計がやっぱり間違っているともいえる。
制約って基本的にはきつく課しておいて、緩めるときに本当に緩める理由があるか考えるほうが安全だよ。
73 ：NAME IS NULL：2005/07/29(金) 23:47:30 ID:???
>>64
連鎖削除・更新は、注文-注文明細とかで考えると、
業務要件では無くＲＤＢ側の物理実装時の都合だと思う。
と、言いつつも管理が面倒なので、アプリ側に実装させて
自分がＤＢを直接弄る場合にのみ、一時的に有効にするのが
ｵﾚｻﾏのやり方だな。
連鎖削除・更新は、注文-注文明細とかで考えると、
業務要件では無くＲＤＢ側の物理実装時の都合だと思う。
と、言いつつも管理が面倒なので、アプリ側に実装させて
自分がＤＢを直接弄る場合にのみ、一時的に有効にするのが
ｵﾚｻﾏのやり方だな。
74 ：NAME IS NULL：2005/07/29(金) 23:56:57 ID:???
NOT NULLの制約については、文字型について
Oracleと、SQLServerで扱いが微妙に違うのがイタイな。
Oracleは、NullとEmptyの違いが無いのに対して
SQLServerは、NullとEmptyを明確に区別する。
そのため、ほとんどのフィールドは、Nullを許可しているな。
考え方は、SQLServerの方が好きだな。
他の、DBってどうなのだろう。。？
Oracleと、SQLServerで扱いが微妙に違うのがイタイな。
Oracleは、NullとEmptyの違いが無いのに対して
SQLServerは、NullとEmptyを明確に区別する。
そのため、ほとんどのフィールドは、Nullを許可しているな。
考え方は、SQLServerの方が好きだな。
他の、DBってどうなのだろう。。？
75 ：NAME IS NULL：2005/07/30(土) 00:17:52 ID:???
さんざん書かれているけど、基本的な考えとしてアプリケーションありきの
モデリングを行うのは、後々の拡張性とか考えると嫌だな。
↓ちょうど良い記事を見つけた。
データは安定している 〜POAからDOAへ
ttp://pcweb.mycom.co.jp/series/stratesys/010/
所で、
制約の管理とか、モデリングツールにより
かなり効率が違ってくると思うのですが、
何かつかってます？
漏れの場合は、Erwin3.5使ってて
最近は値段の関係から、ER/Studioに移行させられそう。。。
モデリングを行うのは、後々の拡張性とか考えると嫌だな。
↓ちょうど良い記事を見つけた。
データは安定している 〜POAからDOAへ
ttp://pcweb.mycom.co.jp/series/stratesys/010/
所で、
制約の管理とか、モデリングツールにより
かなり効率が違ってくると思うのですが、
何かつかってます？
漏れの場合は、Erwin3.5使ってて
最近は値段の関係から、ER/Studioに移行させられそう。。。
76 ：NAME IS NULL：2005/07/30(土) 00:31:04 ID:???
うちはOBERです。
そーんなに使い勝手いいとは思えないかな・・・。
そーんなに使い勝手いいとは思えないかな・・・。
77 ：NAME IS NULL：2005/07/30(土) 06:07:29 ID:???
チラシの裏最強！
78 ：NAME IS NULL：2005/07/30(土) 09:53:03 ID:???
>>77
どの辺がチラシと思った？
どの辺がチラシと思った？
79 ：NAME IS NULL：2005/07/30(土) 22:52:42 ID:???
80 ：NAME IS NULL：2005/07/31(日) 02:33:05 ID:???
81 ：NAME IS NULL：2005/07/31(日) 03:00:10 ID:???
>>80
そういう意味か。。
制約の保守が〜、といった話が出ていたので、
その流れのつもりだったんだけどな。
漏れは、Erwin様にＤＤＬだとか、管理してもらっているので、
モデリングツール無くなると、作業効率がた落ちなんだな。
ＤＢ自体と物理モデルの完全比較とか、使いこなすまでが
大変だけ使いこなすとスコブル便利だよ。
もう、手動で管理する自信ありませんぜ。
そういう意味か。。
制約の保守が〜、といった話が出ていたので、
その流れのつもりだったんだけどな。
漏れは、Erwin様にＤＤＬだとか、管理してもらっているので、
モデリングツール無くなると、作業効率がた落ちなんだな。
ＤＢ自体と物理モデルの完全比較とか、使いこなすまでが
大変だけ使いこなすとスコブル便利だよ。
もう、手動で管理する自信ありませんぜ。
82 ：NAME IS NULL：2005/07/31(日) 03:03:30 ID:???
83 ：NAME IS NULL：2005/08/01(月) 05:30:05 ID:???
>>81
モデリングツールは設計ツールじゃなくて保守ツールと考えると納得いく。
設計は紙と鉛筆が基本だけど、後のことを考えてあえて手間ひまかけてツールを使う。
だから保守をやらない開発メンバーには評判が悪かったりする。
モデリングツールは設計ツールじゃなくて保守ツールと考えると納得いく。
設計は紙と鉛筆が基本だけど、後のことを考えてあえて手間ひまかけてツールを使う。
だから保守をやらない開発メンバーには評判が悪かったりする。
84 ：NAME IS NULL：2005/08/01(月) 10:31:03 ID:???
そうなのか、評判悪いのか。。
漏れは中小規模な案件が多いせいか、
引き継ぎと言う事例が少ないだけで（~-~;
しょうがなしに保守や改善対応している
開発よりのタイプなんだけどな。
そういえば、UMLっぽい物をVisioで
書こうとした時はﾒﾝﾄﾞｸｾと思った。
あんな感じなのかな。
漏れは中小規模な案件が多いせいか、
引き継ぎと言う事例が少ないだけで（~-~;
しょうがなしに保守や改善対応している
開発よりのタイプなんだけどな。
そういえば、UMLっぽい物をVisioで
書こうとした時はﾒﾝﾄﾞｸｾと思った。
あんな感じなのかな。
85 ：NAME IS NULL：2005/08/01(月) 10:48:40 ID:???
「保守を行わない開発メンバー」という
箇所を見落としてた。
とはいえ、統一したフォーマットの
DDL書いてくれるだけでも便利だと
思うのだけどな。
そういった観点か既に保守する立場と（略
箇所を見落としてた。
とはいえ、統一したフォーマットの
DDL書いてくれるだけでも便利だと
思うのだけどな。
そういった観点か既に保守する立場と（略
86 ：NAME IS NULL：2005/08/01(月) 12:08:59 ID:???
チラシの裏書いた本人だが、終盤はモデルツールでやりますよ。
ただ、概念から順次ツールに合わせて落としていくっていうのがどうも制限になって嫌で。
手法の１つとしてはツールの手順でもいいけど、設計ってそこまで理想的に出来ないこと多いし。
とりあえずの概念設計とかはチラシの裏というか裏紙が一番いい。
ただ、概念から順次ツールに合わせて落としていくっていうのがどうも制限になって嫌で。
手法の１つとしてはツールの手順でもいいけど、設計ってそこまで理想的に出来ないこと多いし。
とりあえずの概念設計とかはチラシの裏というか裏紙が一番いい。
87 ：NAME IS NULL：2005/08/01(月) 22:58:35 ID:???
そのままの意味だったとは。。。
そいつぁ 盲点だたよ (^ ^ ;
そいつぁ 盲点だたよ (^ ^ ;
88 ：NAME IS NULL：2006/06/08(木) 23:51:07 ID:???
ここで書き込んでいる人たちはずいぶん専門的な話題が多いようですが、
具体的にいったいどんな規模のどんなシステムに関わってるんでしょうか？？
ここでいう「中小」とはどれくらいのものを指すんだろう・・・。
具体的にいったいどんな規模のどんなシステムに関わってるんでしょうか？？
ここでいう「中小」とはどれくらいのものを指すんだろう・・・。
89 ：NAME IS NULL：2006/06/30(金) 00:59:24 ID:???
中…1000万行程度、数十テーブル程度で同時接続ユーザ数100人程度
小…100万行程度、数テーブル以下で列数最大20-100列、同時接続ユーザ数数名程度
小…100万行程度、数テーブル以下で列数最大20-100列、同時接続ユーザ数数名程度
90 ：NAME IS NULL：2006/08/05(土) 00:40:54 ID:???
今やってるのは
100万行程度、数百テーブルで列数最大100列、同時接続ユーザ数数名程度
ですが・・・
100万行程度、数百テーブルで列数最大100列、同時接続ユーザ数数名程度
ですが・・・
91 ：NAME IS NULL：2006/08/15(火) 00:15:31 ID:???
>90
あまり細かい事を気にすると頭髪的にチャレンジされている方々の仲間入りしちゃうぞ。
あまり細かい事を気にすると頭髪的にチャレンジされている方々の仲間入りしちゃうぞ。
92 ：NAME IS NULL：2006/08/17(木) 11:00:08 ID:???
きみは政治的に正しいやつだね
93 ：NAME IS NULL：2006/11/25(土) 01:59:26 ID:???
てｓｔ
94 ：NAME IS NULL：2007/03/18(日) 01:54:18 ID:???
プログラム側でわかりやすいエラーを出すのはもちろんだけど
制約があればプログラムがバグってても間違ったデータは入らないので
フェールセーフにはなるよね。プログラム側の制御はフールプルーフということで。
制約の付け方が間違ってたら設計者を死刑で。
制約があればプログラムがバグってても間違ったデータは入らないので
フェールセーフにはなるよね。プログラム側の制御はフールプルーフということで。
制約の付け方が間違ってたら設計者を死刑で。
95 ：NAME IS NULL：2007/10/27(土) 22:41:17 ID:???
制約は、Not Null、主キー、一意制約くらいいしか使わない
96 ：NAME IS NULL：2007/11/05(月) 01:17:42 ID:???
97 ：NAME IS NULL：2008/06/21(土) 22:53:28 ID:???
保守してみるか
98 ：NAME IS NULL：2009/01/03(土) 00:07:53 ID:3emwlJX+
>>74
確かに実装レベルでは、Oracleが特殊だが、SQL標準からすると、Oracleが正解。
でも、Oracle8とかOracle9のせいでOracle嫌いになってしまったけどね。
(バグが多いくせにパッチ当てるのも一苦労だし)
で、制約に関しては、参照整合性制約以外は、つけたほうがいいと思う。
参照整合性だけは微妙だと思うけどね。
でも、制約にすべてのエラーチェックを任せるのはいかがなものだと思うよ。
アプリ側でチェックして、最後の砦として、制約を使うのが正解だと思う。
昔みたアプリで、とりあえず、INSERTしてみて、エラーが出たら、制約違反です
とかの処理のがあったけど、言語道断だと思う。
後、デフォルト値(制約じゃないけど)も付けといてもいいと思う。
でも、デフォルト値に設定したいがために、INSERT文で指定しないってのは
言語道断だと思う。
確かに実装レベルでは、Oracleが特殊だが、SQL標準からすると、Oracleが正解。
でも、Oracle8とかOracle9のせいでOracle嫌いになってしまったけどね。
(バグが多いくせにパッチ当てるのも一苦労だし)
で、制約に関しては、参照整合性制約以外は、つけたほうがいいと思う。
参照整合性だけは微妙だと思うけどね。
でも、制約にすべてのエラーチェックを任せるのはいかがなものだと思うよ。
アプリ側でチェックして、最後の砦として、制約を使うのが正解だと思う。
昔みたアプリで、とりあえず、INSERTしてみて、エラーが出たら、制約違反です
とかの処理のがあったけど、言語道断だと思う。
後、デフォルト値(制約じゃないけど)も付けといてもいいと思う。
でも、デフォルト値に設定したいがために、INSERT文で指定しないってのは
言語道断だと思う。
99 ：NAME IS NULL：2009/04/02(木) 10:03:38 ID:???
言語道断・・げんごみちだん？
100 ：NAME IS NULL：2009/04/03(金) 21:37:01 ID:???
>>99
3ヶ月掛けて考えたレスがそれか・・・
3ヶ月掛けて考えたレスがそれか・・・
101 ：NAME IS NULL：2009/04/24(金) 07:29:57 ID:???
>>99
げんごどうだん
げんごどうだん
102 ：NAME IS NULL：2009/07/02(木) 12:27:22 ID:???
保守ついでに。
ITアーキテクトの「やってはいけない」
［データベース設計編］参照整合性制約機能を多用してはいけない
http://itpro.nikkeibp.co.jp/article/COLUMN/20090512/329851/
はてブでは否定的なコメントが多いが、このスレの住人的にはどうなんだろ？
ITアーキテクトの「やってはいけない」
［データベース設計編］参照整合性制約機能を多用してはいけない
http://itpro.nikkeibp.co.jp/article/COLUMN/20090512/329851/
はてブでは否定的なコメントが多いが、このスレの住人的にはどうなんだろ？
103 ：NAME IS NULL：2009/07/03(金) 18:04:26 ID:???
ストアドよりインデックスの方が速いよ。
104 ：NAME IS NULL：2009/07/19(日) 18:08:40 ID:???
データベースの目的によるんじゃないか
ただのストレージとしてなら、参照性合成制約なんか邪魔なだけ
モデルをあらわすものなら、制約付けとくほうがいいのかな
ただのストレージとしてなら、参照性合成制約なんか邪魔なだけ
モデルをあらわすものなら、制約付けとくほうがいいのかな
105 ：NAME IS NULL：2009/07/19(日) 22:31:04 ID:???
商品番号のくだり馬鹿かよ
106 ：NAME IS NULL：2009/08/02(日) 20:10:13 ID:???
>>102
「参照制約を多用してはいけない」とは思うけど、
それは主にレスポンスの問題だな
こいつの挙げてる理由はどうでもいい
・移行時に時間がかかる
→移行なんてそうそうやるもんじゃないし、別に時間かかってもいい
・マスタにないデータが登録できない
→それが正常だし、アプリで制約実装しても同じ問題が起こる
「参照制約を多用してはいけない」とは思うけど、
それは主にレスポンスの問題だな
こいつの挙げてる理由はどうでもいい
・移行時に時間がかかる
→移行なんてそうそうやるもんじゃないし、別に時間かかってもいい
・マスタにないデータが登録できない
→それが正常だし、アプリで制約実装しても同じ問題が起こる
107 ：NAME IS NULL：2009/08/02(日) 20:47:06 ID:???
藤塚 勤也（ふじづか きんや）
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 エグゼクティブITスペシャリスト（データベース）
日頃はオリジナルOSSを中心に，技術開発やそのビジネス化に従事。
特にシステムの中核であるRDBMSには常に着目し，ITスペシャリストとして後進の指導にも注力している。
「RDBMS解剖学」（翔泳社）を共著。
データの人間ってこんなレベルのやつらばかりなのか？
こんなレベルで後進の指導に注力されてもこまるんだがｗ
NTTデータ 基盤システム事業本部 システム方式技術ビジネスユニット OSS技術統括 エグゼクティブITスペシャリスト（データベース）
日頃はオリジナルOSSを中心に，技術開発やそのビジネス化に従事。
特にシステムの中核であるRDBMSには常に着目し，ITスペシャリストとして後進の指導にも注力している。
「RDBMS解剖学」（翔泳社）を共著。
データの人間ってこんなレベルのやつらばかりなのか？
こんなレベルで後進の指導に注力されてもこまるんだがｗ
108 ：NAME IS NULL：2009/08/02(日) 20:53:12 ID:???
基本丸投げで
109 ：名無しさん＠そうだ選挙に行こう：2010/07/11(日) 16:56:08 ID:???
データ社員が使えるとか何の笑い話だ？
110 ：NAME IS NULL：2010/07/13(火) 15:20:02 ID:???
> 通常業務処理の中でも問題になるケースがある。
> 例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。
ふむふむ。
> まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。
ああそうですか。
>仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。
まあそうですね。
>このような業務処理は実行できなくなってしまう。
えええ？
>仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。
はぁぁぁ？
お前が設計してはいけない。
> 例えば，1週間後に発売を予定している商品を先行して仮受注するような業務処理があった場合だ。
ふむふむ。
> まだ発売していないので商品テーブルにはその商品番号のレコードが存在しないとしよう。
ああそうですか。
>仮受注のデータも受注テーブルで管理しようとしても，商品テーブルにない商品番号のデータは追加できない。
まあそうですね。
>このような業務処理は実行できなくなってしまう。
えええ？
>仮受注のときのみ，一時的に参照整合性制約を解除するといった方法は良い設計とはいえない。
はぁぁぁ？
お前が設計してはいけない。
111 ： 【30.7m】 電脳プリオン：2012/05/26(土) 14:52:17.07 ID:??? BE:486490368-PLT(12079)
せやな
112 ：NAME IS NULL：2014/02/27(木) 19:09:42.31 ID:???
>>102
>データを移行する際、先に受注テーブルを移行させようとすると
>参照整合性違反となり、RDBMSはエラーを返す。
>必ず、商品テーブルのデータ移行後に、
>受注テーブルのデータ移行を行わなければならない。
参照元-参照先という関係は半順序だからDAG(非循環有向グラフ)で表現できる
このDAGをトポロジカルソートすれば、
参照整合性違反にならないテーブルの移行順序を機械的に導出できる
これはグラフ・アルゴリズムの初歩的な応用だ(makeコマンドを知っていれば合点がつくと思う)
>仮受注のデータも受注テーブルで管理しようとしても、
>商品テーブルにない商品番号のデータは追加できない。
>このような業務処理は実行できなくなってしまう。
これは業務分析なりDB設計のミス
もし業務ルールにおいて受注より(時系列上で)先行して受注が発生する可能性があるなら、
受注テーブルに商品番号カラムを設けてはならない
代わりに受注番号カラムと商品番号カラムを持つ受注.商品.対応テーブルを追加し、
両カラムのペアにはユニーク制約を、各カラムには参照整合性制約を設定する
この設計は、できれば業務分析時に判断してあらかじめDB設計に盛り込むのがベストであるし、
あるいは分析漏れがあったのならば(分析ミスを認めて)バグを作り込んだDBの再設計に立ち返るべき
こうした上流工程での間違いを正さずに下流工程のアプリ側で整合性検査処理を組ませるからバグが多発する
いいかえると、上流でのミスを下流の小手先で誤摩化そうとする傲慢さがプロジェクト炎上の原因になる
システム設計の基礎である初歩的なアルゴリズムの知識が無く、DB設計の基本や品質保証の定石も知らず、
これでもNTTデータ様のITスペシャリストを名乗れている(>>107)という現実に驚かされる
そして、これほど無能な自称スペシャリストに記事を書かせたITproの見識にも、疑いをいだかざるをえない
>データを移行する際、先に受注テーブルを移行させようとすると
>参照整合性違反となり、RDBMSはエラーを返す。
>必ず、商品テーブルのデータ移行後に、
>受注テーブルのデータ移行を行わなければならない。
参照元-参照先という関係は半順序だからDAG(非循環有向グラフ)で表現できる
このDAGをトポロジカルソートすれば、
参照整合性違反にならないテーブルの移行順序を機械的に導出できる
これはグラフ・アルゴリズムの初歩的な応用だ(makeコマンドを知っていれば合点がつくと思う)
>仮受注のデータも受注テーブルで管理しようとしても、
>商品テーブルにない商品番号のデータは追加できない。
>このような業務処理は実行できなくなってしまう。
これは業務分析なりDB設計のミス
もし業務ルールにおいて受注より(時系列上で)先行して受注が発生する可能性があるなら、
受注テーブルに商品番号カラムを設けてはならない
代わりに受注番号カラムと商品番号カラムを持つ受注.商品.対応テーブルを追加し、
両カラムのペアにはユニーク制約を、各カラムには参照整合性制約を設定する
この設計は、できれば業務分析時に判断してあらかじめDB設計に盛り込むのがベストであるし、
あるいは分析漏れがあったのならば(分析ミスを認めて)バグを作り込んだDBの再設計に立ち返るべき
こうした上流工程での間違いを正さずに下流工程のアプリ側で整合性検査処理を組ませるからバグが多発する
いいかえると、上流でのミスを下流の小手先で誤摩化そうとする傲慢さがプロジェクト炎上の原因になる
システム設計の基礎である初歩的なアルゴリズムの知識が無く、DB設計の基本や品質保証の定石も知らず、
これでもNTTデータ様のITスペシャリストを名乗れている(>>107)という現実に驚かされる
そして、これほど無能な自称スペシャリストに記事を書かせたITproの見識にも、疑いをいだかざるをえない
>>112の「....」の部分を訂正
誤: もし業務ルールにおいて「受注」より(時系列上で)先行して受注が発生する可能性があるなら、
正: もし業務ルールにおいて「商品(の登録)」より(時系列上で)先行して受注が発生する可能性があるなら、
誤: もし業務ルールにおいて「受注」より(時系列上で)先行して受注が発生する可能性があるなら、
正: もし業務ルールにおいて「商品(の登録)」より(時系列上で)先行して受注が発生する可能性があるなら、