気に入った記事をブックマーク
- 気に入った記事を保存できます
保存した記事の一覧は、はてなブックマークで確認・編集ができます
- 記事を読んだ感想やメモを書き残せます
- 非公開でブックマークすることもできます
エントリーの編集
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント22件
- 注目コメント
- 新着コメント
yojik
OOでモデリングするときも、インスタンスが何をもって一意か?というのは何らかの手段(UMLならOCL等をつかって)考えるべきで、複合主キー許容も結局リレーショナルモデルの都合にあわせた設計判断にすぎないと思う。
nippondanji
キーの概念（リレーショナルモデル的に）を誤解してる印象を受ける。最後に紹介されてるリンクを読んでみたけど「ナチュラルキー（自然キー。値が変化し得る一意キー）」という定義は誤り。
nobeans
複合主キーで「なければならない」理由が腑に落ちてないのだけど“いきなりID方式で設計する設計者は、a=F(b,c)のようなデータ要件を見落としてしまう”という話だけなら見落とさなければOKぐらいの話なのかしら
yojik
OOでモデリングするときも、インスタンスが何をもって一意か?というのは何らかの手段(UMLならOCL等をつかって)考えるべきで、複合主キー許容も結局リレーショナルモデルの都合にあわせた設計判断にすぎないと思う。
dekokun
InnoDBは主キーがクラスタインデックスであるわけで、性能面を鑑みて基本的に検索のキーとして使用するキーはなるべく主キーに入っていて欲しいなぁと思うんですよ。というわけで今日も私は複合主キーを採用します。
yass
" 単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかった / RailsといったWEB開発のためのメジャーな開発基盤では、複合主キーの利用を認めていない（使えないわけではない "
asuka0801
第2主キーだけで検索するとうまくクラスタインデックス参照しなかったりするし、個人的にはあまり複合主キーは使いたくない。ノンクラスタインデックス複数作成とかもInsertパフォーマンス劣化で死にかけた思ひで
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
いまの話題をアプリでチェック！
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄が... 定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
ブックマークしたユーザー
すべてのユーザーの
詳細を表示します
詳細を表示します
2013/12/01 リンク