- PR -

DB設計時の主キーデータ型

1|2 次のページへ»
投稿者投稿内容
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-04-26 01:07
今まであまり気にすることなくコーディングをしており、
ふと思ったのですが、みなさんがＤＢを設計するときは、
マスター系のテーブルを作る際の主キーデータ型は何を利用されてますか？

DBMSや要件に左右されることは当たり前ですが、
今まで見てきた中では、VARCHAR型が一番多かった気がします。
ぶさいくろう
ぬし
会議室デビュー日: 2005/11/22
投稿数: 1232
お住まい・勤務地: 川崎市（は俺も含めてロクな人間が住んでないよｗ）
投稿日時: 2007-04-26 01:35
引用:

YMMさんの書き込み (2007-04-26 01:07) より:
今まであまり気にすることなくコーディングをしており、
ふと思ったのですが、みなさんがＤＢを設計するときは、
マスター系のテーブルを作る際の主キーデータ型は何を利用されてますか？

DBMSや要件に左右されることは当たり前ですが、
今まで見てきた中では、VARCHAR型が一番多かった気がします。

数値しか入らないならVARCHARになどしない。
俺の場合はVARCHARが１番多いなんてことはなかったな。

つか、なんのためにこんなこときくの？激しく無意味だと思う。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2007-04-26 09:03
引用:

YMMさんの書き込み (2007-04-26 01:07) より:
DBMSや要件に左右されることは当たり前ですが、
今まで見てきた中では、VARCHAR型が一番多かった気がします。

人為キー(artificial key)ならば型は自由に決められますが、そうでなければ型は要求仕様からおのずと決まるはずです。たとえば、(普通はやりませんが)名前を主キーにするのならば文字列型でありそうなれば varchar でしょう。学生番号を主キーにするのならば int でもよいでしょう。
しかし、ありがちなのは、最初は int でもいいと思っていたのに、あとから、「そうそう、学生番号は学部を示すアルファベットを先頭の桁に付けてね」みたいなことになって要求仕様自体が変わってしまうことが良くあります。そういう苦難を乗り越えてきた人は、最初っから varchar にしておきます。

またこれとは別に、自動裁番(とくに人為キーで)をする場合、DBMS の多くは int でしか自動で付けることができないことがあり、そういう場合は int になってしまいます。DBMS によっては、裁番のロジックの自由度が高く、varchar でもできるものもあるのかもしれませんが。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-04-26 13:40
ご回答ありがとうございます。
私も、varchar型の方が後から、何かあった場合都合がよいかと思っていました。
今のプロジェクトは、MYSQLを利用しており、int型を主キーとして
利用しているのですが、その理由を担当の方に説いたところ、
Oracle のような強力なシーケンスが無く、int型で主キーしか自動裁番を振ることが
できないからという、理由でした。
まさしく、uibonさんがおっしゃるとおりでした。

マスターデータのように更新頻度が少ないデータで桁数も決まっていたら、
CHAR型にして、自動裁番が必要な箇所に関しては、int型で行うということに
落ち着きそうです。

当然のことかもしれないですが、ＤＢＭＳのよって、機能が変わってくるんですね。
勉強になりました。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-04-26 14:37
私の場合、「何とかコード」を主キーにすると、
コード体系が変わったりしたときに苦労するので、
基本的にはそういう値を主キーにはしません。

その「何とかコード」自体で一意性が保障されていても、
あくまで属性の１つと捕らえます。
（複合キーの場合でも同じこと）

ですので、基本的にサロゲートキーのみしか使いません。
型は整数型の自動連番にしています。
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-04-26 18:17
かつのりさんありがとうございます。
業務都合のコード類は、属性として持ち
システム側のキーは、サロゲートを利用したいと思いました。

マスターの定義は、システム毎に変わりますが、
性別、和暦、都道府県(01〜47)などのコードは、
不変的なので主キーとして利用を考えたいと思います。

ありがとうございました。
flatline
大ベテラン
会議室デビュー日: 2005/09/22
投稿数: 102
投稿日時: 2007-04-26 20:14
引用:

マスターの定義は、システム毎に変わりますが、
性別、和暦、都道府県(01〜47)などのコードは、
不変的なので主キーとして利用を考えたいと思います。


それは、やめておいた方が無難では。
基本的に、主キーは意味を持たない整数の連番にすべきだと思います。
ハニワ祭り
大ベテラン
会議室デビュー日: 2005/11/15
投稿数: 115
投稿日時: 2007-04-26 22:15
引用:


基本的に、主キーは意味を持たない整数の連番にすべきだと思います。



どこかの会計パッケージを思い出しますね。
DBMSにもよりますが、主キーがクラスタ化インデックスになるような場合、
代替キーにユニークインデックスを張っても
必ずある程度の性能劣化がおきることは覚悟しておいたほうがいいでしょうね。
汎用性と性能は相反するものですから。


ちなみに適用期間のあるマスタの場合の例をあげると、


{連番、世代番号、適用開始日、適用終了日、業務的候補キー、従属項目…｝

・主キー（連番＋世代番号）
・連番と業務的候補キーは一対一で対応
・同一の連番に対して、適用開始日〜適用終了日の重複は制限
・業務的候補キーにインデックスを作成
・教務的候補キーを画面より入力
・連番のみをトランザクションテーブルに格納

といった感じですかね？



[ メッセージ編集済み 編集者: ハニワ祭り 編集日時 2007-04-26 23:35 ]
1|2 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）