- PR -

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

«前のページへ 1|2
投稿者投稿内容
せん
ぬし
会議室デビュー日: 2002/03/04
投稿数: 397
投稿日時: 2007-04-27 01:47
引用:

そういう苦難を乗り越えてきた人は、最初っから varchar にしておきます。

くるかどうかもわからない要求仕様変更を見据えて上記の設計をすることが
一般的に正しいとは私には思えません。


基本的には以下の事を心がけておけば良いと思います。
引用:

数値しか入らないならVARCHARになどしない。
flatline
大ベテラン
会議室デビュー日: 2005/09/22
投稿数: 102
投稿日時: 2007-04-27 02:06
引用:

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


すみません、ちょっとイメージが沸かなかったのですが、具体的にはどんな感じになりますか？
たとえば、商品マスタみたいなマスタの場合、

[100] [1] [2007-4-1] [2008-3-31] [00123] [商品名Ａ] [5000円]
[100] [2] [2008-4-1] [2009-3-31] [00123] [商品名Ａ] [5250円]

という感じでしょうか？
ゆうじゅん
ぬし
会議室デビュー日: 2004/01/16
投稿数: 347
投稿日時: 2007-04-27 11:24
引用:

せんさんの書き込み (2007-04-27 01:47) より:
引用:

そういう苦難を乗り越えてきた人は、最初っから varchar にしておきます。

くるかどうかもわからない要求仕様変更を見据えて上記の設計をすることが
一般的に正しいとは私には思えません。


基本的には以下の事を心がけておけば良いと思います。
引用:

数値しか入らないならVARCHARになどしない。



私は以下のように、切り分けてますね

１）数字で構成された文字列　→　VARCHAR
　・「＋」で演算した場合は、文字列の連結（10＋11＝1011）
　・「０」プリフィックスが付く
　・桁ごとに意味を持っている（1桁目：種別、２〜３桁：月）
２）数値　→　int
　・「＋」で演算した場合は、加算（10＋11＝21）

例に挙がっていた「学生番号」の場合だったら、１）にします。

あと、経験上ですがコードの拡張をしなければならない場合は、
桁を増やすより、英字を使用するほうが多いと思います。
（桁変更だと、書類のフォーマット変更が発生するため）
YMM
会議室デビュー日: 2007/04/15
投稿数: 15
投稿日時: 2007-04-27 12:42
早速、WEB+DB の総集編を購入し過去記事にあったデータベース設計の基礎知識というところで、勉強させて頂いております。
確認させていただきたく、投稿させていただきました。

例えば、店ごとに指定の休日を格納する関係のテーブルを作成したいと思います。
下記のようなテーブルを作成させていただきました。
休日テーブルと店テーブルの関係は従属関係にあります。
店ごとに休日データを持ちかつ表示順を持ちたいと考えております。
休日テーブルは店テーブル意外と関連することはないとした場合、
この際にも、休日テーブルにも店ID(FK)と表示順は、ユニークし、
休日IDを作成し主キーとして利用したほうがよいのでしょうか。

店テーブル
・店ID(主キー)
・店コード(コード)
・店名

休日テーブル
・休日ID(主キー)
・店ID(FK)
・表示順
・休日日

※店ID(FK)と表示順はユニーク
※店IDと休日IDは自動連番


[ メッセージ編集済み 編集者: YMM 編集日時 2007-04-27 13:11 ]
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2007-04-29 22:40
引用:

ゆうじゅんさんの書き込み (2007-04-27 11:24) より:

２）数値　→　int
　・「＋」で演算した場合は、加算（10＋11＝21）


加えて、エンティティにキーとして望ましい項目が存在いない場合。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-04-30 02:24
好みの問題かと思いますが、私の場合は、
・店舗テーブル
・休日テーブル
・休日と店舗の関連テーブル
を作ります。

システムというドメインを超えて、休日という概念の中に店舗という概念はないので、
私は関係ない属性は付けません。

例えば従業員の休みを同じシステムに追加したいという要件が発生したときに、
・従業員テーブル
・休日テーブルと
・休日と従業員の関連テーブル
で構成することができます。

このときに店舗、従業員のスケジュール一覧が分かるような
カレンダー画面を作る事を考えてください。
SQLそのものは非常にシンプルになると思います。


基本的に好みの問題で、システムが正しく動けば全て正解ですから、
こういう考え方もあるんだな程度に思ってもらえると助かります。
上記テーブル構成について正しいか議論するつもりはありません。
«前のページへ 1|2

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