テクノロジー
主キーはインデックスではない - 設計者の発言

気に入った記事をブックマーク

気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
記事を読んだ感想やメモを書き残せます
非公開でブックマークすることもできます

主キーはインデックスではない - 設計者の発言

テクノロジーカテゴリーの変更を依頼記事元:

watanabek.cocolog-nifty.com

適切な情報に変更

エントリーの編集

エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。

このページのオーナーなので以下のアクションを実行できます

タイトル、本文などの情報を
再取得することができます

コメントを非表示にできますコメント表示の設定

ブックマークしました

ここにツイート内容が記載されますhttps://b.hatena.ne.jp/URLはspanで囲んでください

Twitterで共有

次回からTwitterへ自動リダイレクト

ONにすると、次回以降このダイアログを飛ばしてTwitterに遷移します

537usersがブックマークコメント

コメントするにはログインが必要ですブックマークを追加

ブックマークを追加

よく使うタグ

主キーはインデックスではない - 設計者の発言

537 users

watanabek.cocolog-nifty.com

よく使うタグ

はてなブックマークで
関心をシェアしよう

みんなの興味と感想が集まることで
新しい発見や、深堀りがもっと楽しく

ユーザー登録

アカウントをお持ちの方はログインページへ

記事へのコメント72件

注目コメント
新着コメント

Dursanわたしを主キーにつれてって　　審議中とな？では「うれしいたのしい大主キー」で

2014/08/27リンク

その他

isseium関数従属はだめっていうのとか理論としてデータのあるべき姿としては同意。ただ処理速度の観点とか業務理由(テーブル増やしたり分割するのは影響でかい・社内手続き面倒とか)で正規系崩れてくイメージ

2014/08/27リンク

その他

longroof好き(主キー)にすればいい

2014/08/27リンク

その他

kamei_rioデータベースは理想と現実が乖離してても現場が死ねば存続できるから怖い

2014/08/27リンク

その他

mebiusplus"主キーはインデックスではない" そんなのcolumn001から100まであるような糞構造と比べたら些細な問題。どっちでもいい

2014/08/27リンク

その他

thesecret3「処理過程でのデータの一時保管場所」かもよ。SQLを書かないフレームワークなら既にそうなってる。個人的には「DBが実体」派だけど。

2014/08/27リンク

その他

mikio01そんなもん主キーにすればいい

2014/08/27リンク

その他

ledsun恋の呪文は主キーと決めとキス

2014/08/27リンク

その他

quabbinなんで主キーを全部サロゲートにして後から苦労しているのか、見てて疑問に思っていたけど…なるほどなぁ…。

2014/08/27リンク

その他

anakahala並び順のために主キー！

2014/08/27リンク

その他

anoworlだい主キー

2014/10/10リンク

その他

murasaki11複合主キーはあまりよくないってどこかで読んだ気が。なにが正しいんだ。

2014/08/30リンク

その他

nemobaDBのモデリングって最もリファクタし辛いから、今風の成長する戦略をとると、データストアとビジネスドメインってどんどん分断されてく気がするよ。最もいじり辛いからこそ最初の設計が大事な領域ではあるけど。

2014/08/29リンク

その他

matarilloでたらめなテーブル設計するとあとで泣くよという話だと思うが、ボイスコッド正規形は悪でオレ流こそ正義みたいな主張をする人は残念だ。技術的負債は負債だしクソ設計はクソだぜ。ビジネス価値とは別の軸。

2014/08/29リンク

その他

taketyan難しくてあんま理解できてないけど、データベースは単なるデータの入れ物じゃない、ってことは常に意識してる。現実世界のオブジェクトを表現するようにして、同一性は PK の id でのみ判別。

database

2014/08/28リンク

その他

katzchang“「全テーブルの主キーを"id"にしてしまえばいいではないか。...」などと考えてはいけない。それでは問題がなくなるのではなく、DB設計者が扱うべき重大な問題が「潜航」してしまう”

2014/08/27リンク

その他

tgk「1テーブルに複数の候補キーがあってはならない」と言っているように聞こえる。そんなわけないと思って読み返したがやっぱり言ってる

modeling

2014/08/27リンク

その他

xlc主キーはレコードを特定するために使うのだから、インデックスに決まってる。小難しいことを言うヤツがいるとプロジェクトは破綻する。

2014/08/27リンク

その他

rgfx「主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。」

2014/08/27リンク

その他

mas-higaこんなテーブル実在するん?

2014/08/27リンク

その他

Dryad『主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。』

2014/08/27リンク

その他

akahigeg自分がやってる程度の開発だと全部idで十分だな。

2014/08/27リンク

その他

likkそうか、前職で「主キー」と言わずに「プライマリキー」と言う文化だったのは聞き間違えを避けるためか。＜ブコメ大喜利

2014/08/27リンク

その他

ledsun恋の呪文は主キーと決めとキス

2014/08/27リンク

その他

asamaru正規性自体は、専門知識というよりは一種の規範だと思う。規範が強い原理なのか弱い基準なのかで、崩して良い範囲が決まる。安易に崩すのは論外だが、故にここでの判断は難しく、専門的になる。

2014/08/27リンク

その他

nippondanji主キーは論理的な概念であり、インデックスはその実装、つまり物理。ところで主キーではFDが存在しないことを保証できないのでは。2NFなテーブルには主キーはあるけど自明でないFDは存在する。

2014/08/27リンク

その他

n314メーカーが品番を廃番から使い回しだした、とかの面倒な現実世界のルールと切り離すためにidにするのではなかろうか。

2014/08/27リンク

その他

ngyukiでも主キーがクラスタ化インデックスな RDBMS だと主キーの順番で並んでいると考えることもあると思う

2014/08/27リンク

その他

stealthinu『「全テーブルの主キーを"id"にしてしまえばいいではないか→問題がなくなるのではなく「潜航」してしまう。結果的に関数従属性やユニーク制約や更新不可制約の保全を個々のアプリが引き受ける羽目になる』

2014/08/27リンク

その他

f_oggyいかにもアプリの都合でグダグダになってるテーブルとか見るとイラッと来る気持ちはよく分かる

2014/08/27リンク

その他

Rinta全く共感できなかった。主キーの定義に合致しない主キーは滅びろと言っているように読み取ったが、システム構築の目的はデータモデルの完全性達成ではない。お客様のビジネス目標を達成する道具を作る事が目標だ。

2014/08/27リンク

その他

uturi『こちらの構造の方が綺麗だろ』派 VS 『動けばなんだって良いだろ』派の戦い。だいたい改修時に毎回揉める。

2014/08/27リンク

その他

delphinus35「並び順のために主キーを付ける」！！すごいな。こんなむちゃくちゃな発想は思いも付かなかった。

2014/08/27リンク

その他

estragon「結果的に、関数従属性やユニーク制約や更新不可制約の保全を、個々のアプリが引き受ける羽目になる。その先には、モグラ叩き的なコードの保守地獄が待っている。」

2014/08/27リンク

その他

s025236mysqlの場合、pkが並び順として使われてしまうのでしょうがない。uniqueとfkきっちり使えば問題ないよね？？？

2014/08/27リンク

その他

Jxck“つまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。”

database

2014/08/27リンク

その他

s-tomo主キーを「id」にして困るほど使い込んでない

2014/08/27リンク

その他

masa8aurum >大事な点は、これら以外の関数従属性が「成立してはいけない」という点だ。

Database

2014/08/27リンク

その他

kasumani主キーはインデックスではない　仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをイ

2014/08/27リンク

その他

llill直前のエントリと併せて読みたい。理想像は理解してても業務に精通していないと到達不能であるところから現実に浸食されていくんですよね

2014/08/27リンク

その他

コメントするにはログインが必要ですログインしてコメント

注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています

リンクを埋め込む

以下のコードをコピーしてサイトに埋め込むことができます

プレビュー

はてなブックマークボタンを作成して埋め込むこともできます

規約違反を報告

いまの話題をアプリでチェック！

バナー広告なし
ミュート機能あり
ダークモード搭載

アプリをダウンロード

usersに達しました！

さんが1番目にブックマークした記事「主キーはインデッ...」が注目されています。

気持ちをシェアしよう

ツイートする

主キーはインデックスではない - 設計者の発言

仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思...仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ