データベース
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG0232デフォルトの名無しさん
NGNG一番わかっていないのはチミだよ。
0233デフォルトの名無しさん
NGNG>>220は悪い設計の見本。
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNG0237デフォルトの名無しさん
NGNGやだ。
なお、なぜ悪いのかの理由は>>198の通り（俺の発言じゃないけど）
正規化をしらなければまずはこれを勉強しろ（第三正規形まで）。
データベースの入門書も読んだことないんだろう？
0238デフォルトの名無しさん
NGNGケチはつけるが対案がない。
２３７は厨房の良い見本。
0239デフォルトの名無しさん
NGNG>>182の二の舞だぞ。
もうほっとけ
0240デフォルトの名無しさん
NGNGProductの定義とDelivery処理の要件を提示しろ。
これがわからずに、あーだこーだ言ってもしかたない。
>>220の設計が悪いというのは言えるけどな。
0241デフォルトの名無しさん
NGNG0242デフォルトの名無しさん
NGNG必死に自分の設計を正当化しようともがいているのです。
0243デフォルトの名無しさん
NGNGそうしとくよ。吉外がいるみたいだからな。
>なお、良い設計を示して欲しければ、
>Productの定義とDelivery処理の要件を提示しろ。
は本気だからな＞一年生
俺に限らず、良い設計見本を知りたければ最低限必要だろ。
0244デフォルトの名無しさん
NGNG厨房丸出し。ｶｺﾜﾙｲ
0245デフォルトの名無しさん
NGNG○○を勉強しろ
××を読め
0246PG一年生
NGNGで、結局あなたは良い見本を知らないんでしょ？
0247Error401（243)
NGNG相手するのやめた。さよなら。
0248PG一年生
NGNGさよなら。
0249デフォルトの名無しさん
NGNGところで>>220の意図するところは分かったか？
>>243がいう存在しないはずのデータがあって、
それをキーにしているのは不自然というのはもっともだけど
とりあえず、あれが一番よく使われる設計パターンだ。
0250デフォルトの名無しさん
NGNGもう寝よ。
0251PG一年生
NGNG>>220は理解しました。
でも、外部結合の結果は結局Nullの列ができるわけだから、
PRIMARY KEY制約を用いず、UNIQUE制約だけにするというのも
捨てがたい気がする。パフォーマンスが劣化するのは理解しているが、
業務的に実用に耐えるレスポンスなら
「Nullを含む主キーがあっても良いのでは？」という疑問は晴れません。
0252デフォルトの名無しさん
NGNG0253デフォルトの名無しさん
NGNG0254デフォルトの名無しさん
NGNG俺もそれに同意。厨房ばっかで困るよな、相棒。
0255デフォルトの名無しさん
NGNG>>251
Nullを含まないものを主キーとするというのは定義。
よって、主キーにはNullを含んではいけない。
Q.E.D.
0256PG一年生
NGNGNullじゃなくて"*"なんてヘンな記号ならいいの？
Nullなんて実装手段を「定義」だなんていわれても......
0257デフォルトの名無しさん
NGNG>Nullじゃなくて"*"なんてヘンな記号ならいいの？
良いか悪いかを俺に聞かれてもこまる。
それは要件次第であり、それを知っているのは君だけだ。
>Nullなんて実装手段を「定義」だなんていわれても
nullは「実装手段」などではない。「未定義（不定）状態」という概念。
0258デフォルトの名無しさん
NGNG256の言うとおり、番号未発番という状態を示すのにNULLを用いているに過ぎない。
表の論理的主キーなんてその値がNULLをとるか否かなど考慮しない。
0259デフォルトの名無しさん
NGNGそれは定義(それもいうなら定理だろ)でもなんでもなく、
RDBMS製品の仕様に過ぎない。
0260デフォルトの名無しさん
NGNGそうではない。
だとすると、なぜRDBMSの論理値が３つの値を取ることを前提に
理論構築されていることを説明できるのだ？
0261PG一年生
NGNG番号未発番という状態を表すのにNullを用いてはならないと言っているだけですか？
0262デフォルトの名無しさん
NGNGその通り。
主キーの要件は「タプルを一意に決定できるもの」であり、
nullは「不定」を現す概念だのだから、主キーには使えないとしている。
これは定義なのだから、いくら「nullを主キーに使いたい」と言っても
駄目なのだ。
多くの（全てのかもしれない）RDBMSの実装では、「主キー」を
primary keyというconstraint（制約）で実装しているのだから、
primary keyにnullが使えないのは当然のこと。
Q.E.D.
0263デフォルトの名無しさん
NGNGされているそうだが、俺はそれを知らないし、説明できない。
なお、俺が説明したことも誤りがある可能性はあるので、
その辺は承知しておいてくれ。
0264デフォルトの名無しさん
NGNGネロ
0265デフォルトの名無しさん
NGNGE.F.Coddも後悔しているというようなことをどこかで読んだ気がする。
（これは非常に曖昧な記憶なので間違っている可能性大）
Googleで検索してみたが、それらしいのがいくつかあったので、
興味があるなら、読んでみると良い。（E.F.Codd + null)
0266デフォルトの名無しさん
NGNG俺は起きたばかりなんだが（藁
0267デフォルトの名無しさん
NGNG未発送状態を"*"として、>>166のテーブルでProduct#+Delivery#を
PKとして良いのか？
あの表が他の表から完全に独立していて、なおかつ、将来拡張が
無く、Delivery#だけで、他と識別する必要がなければそれでよい。
つまり要件次第だな。
しかし、将来必ず更新される項目をPKに入れておくのは一般には
良くない。なぜならば、その項目をFKとして持つ表があった場合
Delivery#を更新する場合に、FKとして持つ表も更新しなければ
ならなくなる。
これは容易にシステム全体のデータの整合性を崩してしまう要因になる。
（ツールによるad hocな更新をしてしまったなど）。
ということで、「後から発送番号が付けられる」場合は、それを
単なる属性値として持っておくのが良い。
代わりに、システムが付番する「発送受付番号」のようなものを
作りPKとしておく。
つまり>>174のようにしておく。
>>202ということなので、今の実装で問題が無かったというオチだな。
なお、>>214は冗長だと思う。
特に「発送番号が付番済のもの」をひとまとまりに管理する必要が
なければ、テーブルを分ける必要がないと思う。
まぁ、データモデリングは人それぞれで、唯一の正解というものは
無いのが普通なので、どれが正解、どれが間違いとは一概には言えないもの。
ただし「無意味なSerial#」や「無意味な非正規化」は
間違いだとはいえると思う。
0268デフォルトの名無しさん
NGNGFK constraintを付けた場合、UPDATE出来なくなる実装のRDBMSが
あったような。これはRDBMSの実装依存の部分かもな。
更新されるPKなんてここ最近使ったこと無いので、>>267は微妙に嘘が
混じってる可能性があるので注意。
0269mage
NGNG0270MB
NGNG＞これは定義なのだから、いくら「nullを主キーに使いたい」と言っても駄目なのだ。
なんでその定義に従わなければならないんですか？
実装レベルでは、nullを許した方が性能がよくてもなおその定義に従うメリット
はなんですか？
0271デフォルトの名無しさん
NGNGというのであれば、主キーにnullを許す処理系を作って使えばいいじゃん。
いつまで、駄々こねてんだ。
0272デフォルトの名無しさん
NGNGPostgreSQLかMySQLを改造すれば？
俺は今まで主キーにnullを許すRDBMSを見たこと無いが、
それはそれなりの理由があると思う。それが何かは知らないけど。
そういや、主キーは更新不可というRDBもあったな。
0273MB
NGNG初カキコなんですけど..........
0274デフォルトの名無しさん
NGNG>実装レベルでは、nullを許した方が性能がよくてもなおその定義に従うメリット
>はなんですか？
メリットなんかないよ。だから、>>271-272の言うように、自分の好きな
使用でRDBを作ってください。
0275デフォルトの名無しさん
NGNG主キーにnullを許すと、「null = nullが真」とせざるを得ない。
なぜならば、FKとしてそのPKを指定したときのことを考えれば明らか。
一方、「nullはあらゆるものと一致しない」という定義がある。
これは矛盾している。
主キーにnullを許すのであれば、「null=nullが真」という前提で
理論構築、実装をしなければならない。
そんなことするのめんどくさいし、移植性も損なわれるので、
既存の仕組みに従ったほうが良い。
これがメリット。
0276デフォルトの名無しさん
NGNGなんか神学論争みたいだね。
0277デフォルトの名無しさん
NGNGそんなことないよ。
単純に、tbl1.col1(PK) tbl1.col1(FK)のときに、
select tbl1.col2, tbl2.col2 from tbl1, tbl2
where tbl1.col1 = tbl2.col1
がマッチしないよってだけ。だから、nullは「一意」という場面では
使えないよってこと。
使いたければ、ありとあらゆるものを変更する必要があるよってこと。
0278デフォルトの名無しさん
NGNG（正）単純に、tbl1.col1(PK) tbl2.col1(FK)のときに、
0279デフォルトの名無しさん
NGNGﾔﾊﾟｰﾘ、神学論争だ。
イスラムを侵攻するなら偶像を破壊せよ！
0280デフォルトの名無しさん
NGNGだから、違うって。純粋に集合論モデルの問題。
上のほうで誰か言ってたけど、E.F.Codd博士もnullの取り扱いには
困ったらしい。何度か理論体系の方向転換をしたらしいぞ。
0281デフォルトの名無しさん
NGNGいかに論理に忠実か、なんだろうね。
0282デフォルトの名無しさん
NGNGおまえら説明してください。
0283デフォルトの名無しさん
NGNG一度でも学んだことがあるかどうかも併記して置きなさい。
0284デフォルトの名無しさん
NGNG検索が頻繁に行われる行以外のインデックス対象列をすべてNULLに
設定しておくとインデックスの件数を抑制でき、NULL以外の行の
検索速度を上げることができる。
パフォーマンスチューニングのテクとしては結構知られている手法だ。
0285デフォルトの名無しさん
NGNG中学校でてれば計算できるよね。
高校卒業してるんだったら、列の選択時にNullかどうかをチェックするコストも
全体の計算量に入れてみてね。
選択した列のがNullになっているかどうかをチェックするアプリケーションの
チェックにかかる計算料も数えておくとさらによいね。
0286デフォルトの名無しさん
NGNG0287デフォルトの名無しさん
NGNGで教えてもらったテクだよ。
0288デフォルトの名無しさん
NGNGJETエンジンのマニュアルか？
0289デフォルトの名無しさん
NGNGOracle7.0.x時代の話か？
0290デフォルトの名無しさん
NGNG8.0.4時代でっせ。
0291デフォルトの名無しさん
NGNGクラスタ化してるかしてないかの違いはあるがね。
0292デフォルトの名無しさん
NGNGnullは必要な時に使う。これ常識。
そんな小手先テクニックぎっしりのテーブルなんか使いたくないな（藁
0293デフォルトの名無しさん
NGNGその新規追加行をバッチ処理で夜間に更新する。
７千万件の全行を対象にしたインデックスだと数分かかる処理が、
新規追加行以外のインデックス対象列をすべてNULLにしておくと
インデックスは１万件弱の新規行のみで作られるため、処理時間が
数十秒になった。
0294デフォルトの名無しさん
NGNG設計が悪い（藁
0295デフォルトの名無しさん
NGNGどんな設計だったの？
0297さらでぃん
NGNG0298デフォルトの名無しさん
NGNGそれって、そもそもNull可にすべきだったカラムをNot Nullにしてたって
だけの話なんでしょ。それは概念モデルレベルでの設計ミス。
夜間バッチで大量に更新処理が入る場合は、Indexを削除して、
処理をするのが普通じゃないか？
Indexがある状況で、夜間バッチで更新時間を数分かかるのを
数十秒にするためだけに、Null不可のカラムをNull可にするのは
変だと思うぞ。
0299デフォルトの名無しさん
NGNG0300デフォルトの名無しさん
NGNG＞そもそもNull可にすべきだったカラムをNot Nullにしてた
プライマリキーはNot Nullにできないんだよ。知らないの？
＞Indexを削除して、処理をするのが普通じゃないか？
７千万件のうちの１万件を検索更新する処理にインデックス削除したらもっと遅くなるよ。
0301デフォルトの名無しさん
NGNG0302デフォルトの名無しさん
NGNG当該のカラムはプライマリーキーの中のいカラムなんだよ。
0303さらでぃん
NGNG効果はどうあれ、理論に抵触する設計は認められないって立場なんだよ。
0304デフォルトの名無しさん
NGNG話が良くわからんが、主キー以外のカラムで、Null可にすべき
カラムをNull不可にしていた。そこにIndexを作成していた。
で、それをNull可にしたら速くなった。
つーこと？
だったら、もともとNull不可にしてたのが間違い。
Indexの再作成は確かに遅そうだな。俺の間違い。撤回する。
0306さらでぃん
NGNG本来主キーの中であるべき１カラムのムライマリキー制約を外し、
ユニーク制約のみにした。
それにより、夜間バッチで更新対象の１万件以外の当該カラムを
NULLにすることが可能になった。
0307292
NGNGwhere col1 = col2
とやっていたはず。
ところがこれをnull可にすると、マッチするはずだったものがマッチしなくなる。
で、全体を見直し、プログラムの変更をし、テストしなおす必要がある。
別に「理論」でいっているわけじゃなくて、null値属性を変えると、
とんでもない作業が発生する可能性があるから、良く考えて
設計しておくって話。
0309デフォルトの名無しさん
NGNG要するに、本来主キーでないものを主キーにするために、無理やり
Not Nullにしてたってこと？
だったら、それこそ設計ミス。
0310デフォルトの名無しさん
NGNGテクニックをごっちゃにするから話がおかしくなる。
E.F.Coddを起源とするRDBのモデルにいちゃもんをつけたいなら、
新規にモデルを提唱して広めろ。誰も止めんぞ（藁
0311デフォルトの名無しさん
NGNGきちんとRDBの仕組みを理解しろ(w
0312デフォルトの名無しさん
NGNGお前ら刹那的すぎ。
教科書レベルのRDBの設計の基礎を押さえているだけで
貴重な人材だと言うことでよろしいか？
0313デフォルトの名無しさん
NGNG違うか。
0314デフォルトの名無しさん
NGNG教科書レベルの事もきっちり押さえていない奴多すぎる。
0315デフォルトの名無しさん
NGNGデース
0316デフォルトの名無しさん
NGNG0317デフォルトの名無しさん
NGNG>>56
RBSとかTEMPとかREDOLOG置き場とかINDEX領域とかUSER領域とか、
同じディスク装置の上に入れてるだろ。
OracleのDBA向けの本を買って、テーブルスペースの
切り方を学んで、稟議書を書いてHDD買い足しなさい。
物理的に、それらのセグメントを分割しなさい。
0318デフォルトの名無しさん
NGNG「正規化」を勉強してから出直せ(ﾌﾟﾌﾟﾌﾟ
0319デフォルトの名無しさん
NGNGというか、教科書レベルを*理解できない*奴が多いみたいだな（藁
0320デフォルトの名無しさん
NGNGいいかんじに知識が偏るらしいな
0321312
NGNGワシの暇をつぶしてくれ
0322デフォルトの名無しさん
NGNG的確な洞察により、反論は無いと思われます（藁
0323デフォルトの名無しさん
NGNG0324デフォルトの名無しさん
NGNG空白も入る。
dateやdatetime型はDBの種類によって精度が違うし、
バージョンによってサイズや精度が変わる（かもしれん）ので
あまり推奨されていない。
0325デフォルトの名無しさん
NGNGDATE型なんて使わないな。
ついでにCHAR型も使わない。
NUNMER型も使わない。
全部VARCHAR2型だな。
使うときにキャストすればいい。
0326デフォルトの名無しさん
NGNG0327プミポン
NGNGついでに全部Varchar2(2000)すれば？
ExcelやAccessのValiant型と同じ。
0328デフォルトの名無しさん
NGNG0329デフォルトの名無しさん
NGNG0330デフォルトの名無しさん
NGNG0331デフォルトの名無しさん
NGNG使うのが吉。つーか、常識。
CHARにこだわるのは、化石COBOLER。あるいは、ネタ。
■ このスレッドは過去ログ倉庫に格納されています