Q&A
回答依頼もらったけど、その前に複合プライマリーキーについて調べてみてください。
それでQ1Q2またそれ以外の疑問の多くも解決するのではないかと思われます。また、調べて上で残る疑問はある（はず）と思いますが、それは開発者・設計者の思想によるものなので正解はないです。
Rails初心者エンジニアです。
新規にWebアプリ（マーケットプレイス）を構築し、AWS上にデプロイしたいと考えております。
新規サービスの立ち上げで、フルスクラッチで進める予定で、データ含めて、ゼロからのDB設計となります。
DBはRDB（MariaDB）を使用予定です。
現在、参考書籍：達人に学ぶDB設計を一通り読み、データベースの論理設計を始めておりますが、「主キー/ナチュラルキー/サロゲートキー」に関して、十分に理解できておらず、質問させてください。
###現状理解
参考書籍からの抜粋となりますが、「極力サロゲートキーの使用は避けて、ナチュラルキーを主キーとするようモデリングするべき」が一般原則であるとの理解です。
一方で、Rails（Active Record）ではサロゲートキーが強制されている？
参考サイト1：railsのテーブル名や主キーはcocで厳格なルールがあるおかげで可読性も高い
参考サイト2：代理キーとナチュラルキー
###質問
Q1. DB側でレコード登録時に自動発行されるIDは、サロゲートキー（代理キー）と呼ばれるものでしょうか
（Userテーブルを作成した際に、デフォルトで用意されているカラムuser_idは、サロゲートキーに該当するカラムでしょうか）
Q2. DB側で自動発行されるIDとは別に、一意となるコード体系を、別途定義・発番する必要性はあるでしょうか。具体的には、マーケットプレイス（ECサイト）一般論として、例えば商品テーブルやショップテーブルについて、DB側で自動発行されるproduct_id, shop_idとは別に、商品コード、ショップコードといった、コード体系の定義・発番は必要となるものでしょうか
その書籍を読んでないんでわからんけど、どういう文脈で
> 「極力サロゲートキーの使用は避けて、ナチュラルキーを主キーとするようモデリングするべき」が一般原則
という言葉が出てるんだろう。
論理モデルを考える段階ではナチュラルキーを使うのは自然という意見ならまぁわかるけど、物理モデルの設計段階についてもそんな制約をするのが一般的とは聞いたことがないけど。
それこそ実際にアプリケーション側や利用するフレームワークに合わせて柔軟に考えられない「一般原則」とやらに意味があるとは到底思えない。
>gentaroさん
文脈としては、論理設計のグレーノウハウとして紹介されておりました。誤解を招くような記載ですみませんでした。
確認したいのですが、Rails（Active Record）では、idというカラムが自動的に作成され、デフォルトでテーブルの主キーに使われます。このように、物理設計の段階で、サロゲートキーが主キーとなることが分かっていても、論理設計ではサロゲートキーは無いものとして、自然キーで主キーを決めていくことが一般的なのでしょうか。
素人感覚で申し訳ございませんが、論理設計の主キーと、物理設計の主キーが異なることに違和感があり・・・。
論理モデルは実装を意識しません。
つまりRailsを使うとか関係ない次元で設計します。
gentaroさん、
ありがとうございます。論理モデルと物理モデルをごっちゃにして考えてたことが私が混乱してしまった要因だったようです。
極端な例ですが、商品名だけの商品テーブルがあったとして、私は物理モデルではid がふられて一意になるから、論理モデルの段階では商品コードの必要性が無いと思ってました。物理モデルと切り離して考えると、論理モデルの段階で、レコードを一意にするために商品コードが必要となるのだなと、理解しました。
間違っておりましたらご指摘頂けますと幸いです。
とりあえず回答書きましたが、まぁだいたいそんなところです。
回答1件
0
ベストアンサー
たぶん論理モデルと物理モデルの違いがわかっていないという感想です。
論理モデルは、その名の通り問題領域についての論理的なモデリングを行います。
その場合、エンティティの一意性を表すのにサロゲートキーが登場するのは不自然です。
「社員」エンティティの一意性は「社員番号」で表されるのが自然であり、なんだかよくわからない「機械的に振ったID」みたいなものが登場する事はあり得ません。
そもそもそのビジネスドメインの分析段階において「機械的に振ったID」なんて登場するはずがないからです。
あなたの顧客から要件をヒアリングしている時に「このシステム上、うちの社員はDBで生成される機械的に振ったIDで管理します」なんて言うわけがありません。そのDBはこれから作られるものであって、まだ存在しないんだから。
あくまでユーザー目線では「社員番号」のようなの自然キーが存在するはずです。
物理モデルは、実際のプログラムと対になるものなので、プログラミングの都合で現れる「機械的に振ったID」が登場するのは自然です。
その場合のナチュラルキーは、実際にプログラム上で「社員」レコードを一意に特定するために使うのが適切とは限りません。
質問文のようにRailsの既定の規約に従うことが出来ないほか、社員番号が「A0001」のような数値型ではなく文字列型の場合、これを主キーとして検索するのはパフォーマンス上好ましくないケースも考えられます。
投稿2020/12/02 14:38
総合スコア8947
ご回答ありがとうございます！
物理モデルと論理モデルを切り離して考えることで、整理できました。
論理モデルを考える際は、あくまで業務上の観点でレコードを一意に特定できるキー（自然キー）が必要、と理解しました。
念のため、質問Q1、Q2に自己回答してみると以下の通りの理解ですが、あってますでしょうか？？
Q1: Yes
Q2: 業務要件次第で一概には言えないものの、基本的にはYesと考えています。
（各ショップで既にコードが存在している場合は、既存コードの活用を検討？）
Q2については論理モデルに含まれている以上業務上必要になる項目と認識できるので、必然的理物理モデルにも含まれるのが普通です。
ただしそれを物理モデルでサロゲートキーを主キーとする場合、それらの自然キーだった項目は、UNIQUE制約が付いた項目とする事が多いんじゃないでしょうか。
おかげさまでDB設計の理解が深まりました。ご回答ありがとうございました！
あなたの回答
tips
プレビュー
