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

>>934
一般的には付けたほうがいい。
HACKしたわけではないけど列指向データベースとかは余り有益ではないかも。

DB初心者です。
今、改修してるシステムのDBは9割以上のテーブルに主キーが設定されていません。
その代わり、全てのテーブルにインデックスは設定されています。
これは主キーを設定してもしなくても同じなのでしょうか。

これ次スレ必要なんかしら

>>936
同じではないけど、問題ないなら主キーの設定はしなくてもいい。
そもそも、主キーの設定は必須ではないからね。

インデックスってのが、ユニークインデックスなら、実用上問題は少ない
ほとんどのDBMS実装では、主キー=Not NULL制約+ユニークインデックスだと思っていいかと

ユニークでないインデックスなら、そのテーブルは行を特定できない可能性がある
それで問題ないなら主キーなくてもいいんじゃね

>>1
全カラムでユニークであることは維持しないと。
完全に重複してるデータがどんどん入ってしまうと、さすがに後の処理が厄介だね。
データ設計段階で冗長なカラムを付加してでも主キーを設定してデータベースシステムに任せるか、
すべてプログラム側で一意性を維持させるかということかな。

主キーはあるが、参照制約は全く無い
単なるインデックス+UNIQUE+NOT NULL制約のためだけに使ってる感じ

そういうのって、どうなんだろう

ari

>>941
汎用的なスキーマにするにはそうせざるを得ないな。
ERPとかそうなってるだろ。
無論論理設計段階で要件がかちっと決められる場合はそうではないけど、
ソーシャルとかで大量のクエリを捌かないとならないばあいはあえて参照整合性は付けないかな。遅いから。

参照制約も、参照先テーブルと参照元テーブルを、何がしらかの拡張系JOINを使って
結合すると、ON句を指定しないでもその参照制約を用いての自然な外部結合結果を
返してくれる、みたいなメリットがあったら、もっとみんな使うんじゃないのかなぁ、とか
妄想することがあるんだが、そういう実装ってあるのかな?

MSACCESS

tablename_pkey ってインデックス名だからプライマリキーだと思ったら単なるunique indexだった……

プライマリキーが複数（組）設定されてるTBLを
見たことがある人は手をあげて

Alternative Keyなら設定すっぞ
インデックス名をPK_<TABLENAME>_1とかしたら
一瞬頭をひねるだろう。
フハハハ

>>947
Oracleでは設定できんのだが、できる実装があるのか?

Oracleでも出来ますよ

CONSTRAINT <TABLE名> PRIMARY KEY (<KEY1>,<KEY2>,...) USING INDEX

○<制約名>
×<TABLE名>

それは単に、複数列によるプライマリキーってことなのでは

DB初心者で馬鹿な俺に教えてくれ

PKとは唯一無二のカラム（例えば顧客マスタの「顧客コード」）で、
所謂複数列によるPKとやらはユニークキーという認識で合っているのか？

>>953
RDBに限っていうと、列が単一でも、複数でもキー候補となりうる。
列またはその集合(複数の列)を指定するとテーブルの中の組を
一意に識別できるならばその列またはその集合はキー候補です。
キー候補のうちで、任意のものをプライマリーキーに指定できます。
任意のものだから、どれでもよい。
プライマリーキーは多くの場合、テーブル生成時に指定することが
許されているので特別な何かと思いがちですが、データベースシステムが
常にプライマリーキーの存在に注意して動作してくれるという点を除けば
論理的には他のキー候補と何等差はありません。

>>954
教科書的な答えなら、このスレの >>1 - >>150 くらいの中で出尽くしてる
のではないか。プライマリーキーに関する議論としては、ウェブやブログでは
ほとんど見つけることのできない情報源になっていると思う。

>>944
キャシエ

仕事でよく新規テーブルを作るんだが、
レコード数が１年で１万行程度だったら主キーとかインデックスとかつけないな。
理由は考えるのがめんどくせーから。

シンプルに、よりシンプルに！がモットーです。

主キーはつけないと後で泣き見るぞ

主キー無しで数千万レコードもあるトランザクションテーブルの面倒見ているから、主キー無しの酷さはよく知っている。
全く同じ行が複数ヒットするんだが、別々の注文なのか、１つの注文が不具合で２行になったのか。
インサート日は時間まで無くて困る。

>>957が設計してそれを>>959が保守していると....

ｶﾜｲｿｽ

>>960
数千年・・・

用途による

つけといて困ることはないけど
つけとかないと困る

>>964
必要のない **ID といった項目が無闇と多くなる。

それはサロゲートキーといいます

UUIDでもいいから主キーはつけておいてくれ。

その目的は？

ないと行が特定できない可能性があるからだろ

サロゲートキーに意味はないんだから行は特定できないでしょ
っていんたいんだろう

特定できりゃ何でもいいってわけじゃないからねぇ。
設計中に全フィールド足しても主キーにならないテーブルなんてものが出てきてしまったら普通は
設計あるいはモデリングの失敗だから、そこで立ち返って検討しなおすべきであって、勝手なキーを
くっつけて「主キーができたから大丈夫」なんて済ませるべきじゃないってことだろう。
例えば>>959の例で、このテーブルに何かユニークなキーを追加したところでほとんど何の
解決にもならんし。

特定の1行を削除できなくなるからだろ
（サロゲートキーのどの行でもいいけど、とにかくそのデータから1行だけ消したいって場合もある）

あー、ホスト移行とかDWH系のテーブルはGUIツールとかでポチッと消せなくて面倒くさいときがあるな

同じレコードが何件存在するかが情報として必要な場合？
そういうのは明示的に件数を持とうよ。

結論
DB設計をしっかりやればおｋ
それを適当にやってたらクズ

>>973
俺DWHの開発してたことあるけどネティーザって主キー設定しても
実際には主キーが効かないっていうイミフな仕組みだったな
データ突っ込むときに自分で気をつけろってマヌアルに書いてあった

あれは二度とやりたくない

データがどう入るか分からんから
リーダーに主キーを消されたことあったな。

そのどうデータが入るかわからないテーブルで
バグ出したら、こっちの責任になるんだが。。

どう入るか判らんから制約つけるのに馬鹿みたい

>>978
最初に集合ありき。それを見つめて制約がでてくる。
そういう帰納論理的な考え方も魅力はあるよ。

どういうデータが来るかとどういうデータを入れるべきかは区別して考えないとな。

キリッ、を忘れてるな

朝のダイニングは少し広々としていた．
彼女はいつもきちんとしていて，忘れ物などあろうはずもない．
ただ微かな残り香だけがのこっていた．

朝食の用意をしよう．
一人分だからといきなりの手抜きは，なんだかあのひとに申し訳ないように思えた．
いつものメニューでいこう．

ふと食卓の紙片に目がいった．小ぶりの花瓶に隠れるように置いてある紙片を
取り上げたとたんに抑えていた涙がこぼれる．

一言「すき」とだけ書いたあのひとは一体，どんな思いでこれを書いたのだろう．
紙片を握りしめ，もういちど視線をもどすとそこにはいつものテーブル．
もうそこに「すき」と書いた紙片はない．「すき」はもうテーブルにないのだ．
シュキーのないテーブルとはまさにこのことだ．デービーってほんとに素晴らしいものですね．

ちょっとワロタ

三流だな