サロゲート単独主キー vs 複合主キー問題、復習編 - たなかこういちの開発ノート
こちらの会に参加いたしました。 「単独主キー主義」の是非を問う＜超高速開発コミュニティ＆第57回IT勉強宴会in東京＞ ※“予習編”の記事もご覧ください。 ◇ 懇親会含め活発に意見交換がなされ、いわゆる“学びしかなかった”会となりました。 このテーマ立ては非常に多くの文脈を含んでいて、それを紐解くこと自体、複合主キーを的確に見出すのと同じような困難さがあるように思えました。 DDDでもそうなのですが、「ユビキタス言語を捉え、定義せよ」といいつつ、DDD自体を語る言葉にブレが内包されたままです。（※DDDの自己言及的な性質）複合主キー問題もまた、この問題の構造モデル自体にバリエーションがあるようです。まーそれも当然で、DDDのいう境界付けられたコンテキストが多様に異なるところの立場から語られているからです。 ■ 改めて論点まとめ それでも、論点は、つまりは文脈は、次の三つに集約されそうです。
外部キーのデメリットとIDリクワイアド - 浜村拓夫の世界
ＲＤＢの設計で、先駆者のお知恵を拝借したい。 ・主キーは、自然キーか代理キーか？ ・外部キーは、不要か？ 調べてみたら、少し混乱してきた。 いろんな派閥があるみたいだけど、どれも一長一短で、各立場に一理ある？ 2006-08-22 - 極北データモデリング ABDでは、外部キーを、resourceだけでなくeventからも追放する。 楽々ERDレッスンで提唱されていた「コードを外部キーにしない。identifierを外部キーにする」ということを徹底すると、外部キーというものの意味が変わってくる。 ていうか意味が純化される。外部キーとは、「記録しておきたい事実」そのものではなく、記録したい事実を参照するためのポインタになる。 ABDの感想 - 世界線航跡蔵 resource の中に Relationship(外部キー)が混在していることのおかしさ IREが沢山発生してしまうことによる結合コス
論理設計のグレーノウハウ サロゲートキー
前回まではアンチパターンやバッドノウハウについて学習してきましたが、今回はグレーノウハウについて特集します。 グレーノウハウとは読んで字のごとくホワイトともブラックとも言えないという手法ですね。 つまりある程度の効果もあるけれども、堂々と正しいとは言えない設計のことです。 ポイントとしては 完全に否定はできない 使うなら節度をもち、リスクを踏まえて ということですね。それでは以下見ていきます。 主キーが存在しないときのサロゲートキー データベースではコードなどのキーによってユニークな組み合わせをつくれることが理想です。こういったキーを主キーといい、一つのキーだけで特定できない場合は複数のキーを組み合わせる複合主キーを使用します。 そうはいっても実務では必ずしもユーザーが使用しているキーがユニークになるとは限りません。 使いまわしをしている というケースも考えらなくはありません。 このような
メモ: 複合主キーを云々いう前に足りなかったこと - 虎塚
先日、データベース設計で、ナチュラルキーの組合せを使った複合主キーと、その代替となるサロゲートキーのどちらを使うか、という話を書きました。 複合主キーを避けるべき理由 - 虎塚 月末までには、改めて考えを整理するつもりでした。しかし、残念ながら、今の自分の知識ではムリそうです。そこで、考えたことを少しずつ出力することにしました。 この問題について考えるべき（だった）こと 前回の記事に足りなかった観点が3つあります。 データベースの論理設計と物理設計を分ける 複数ある要素の一部にだけ言及していると自覚する すべては程度問題である これらを1つずつ考えてみます。 1. 論理設計と物理設計を分ける まず、データベースの論理設計と物理設計を分けて考える必要がありました。非常に、基本的なことですが・・・ 論理設計で、ユニーク制約が必要なキーと、行を一意に特定するキー（候補キー）を特定します。もちろん
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
ID or not ID - A.R.N [日記]
おぉ、ガチだ。 [RDBMS]複合主キー？ 18:57 ･･･まだそんなこと言ってる人いるのか。 id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派（＝私）と複合主キー派（＝モデラー）でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1。 たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるよ
![ID or not ID - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b9f5dd5b04b969b65543d66daeabf09d2f67327/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064335398%2F1555805246)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
