- PR -

区分と別テーブル

1
投票結果総投票数:18
区分 16 88.89%
別テーブル 2 11.11%
  • 投票は恣意的に行われます。統計的な調査と異なり、投票データの正確性や標本の代表性は保証されません。
  • 投票結果の正当性や公平性について、@ITは一切保証も関与もいたしません。
投稿者投稿内容
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-07-01 15:09
こんにちは。

DatabaseのExpertである俺にも聞きたいことがあります。
(冗談ね、本気にしてはいけません)

テーブルになんとか区分という項目をつけて、
情報を区別することがよーーく見かけます。
たとえば、削除区分とか(た〜くさんあります)。
何も問題ないですが、ときと場合によっては
区分ではなく、別テーブルに保存することも
とても有効でかつみやすいことがあると思います。

それでみなさんに、区分派なのか別テーブル派なのかを
投票していただきたいです。

#この場合は明らかに、どちらでも可能ということが前提です。

_________________
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-07-01 17:45
よろしければ、理由なんかも
聞かせて頂けるとうれしいっす。

_________________
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2004-07-02 10:31
正直な話し意味が解らず憶測で「区分」に投稿しました。

区分と言えど、その情報が現す対象物の属性です。
例えば、社員マスタの性別区分は人の属性を表していますが、
これを表として分割する理由が逆に解りません。

もし上記の考えを用いると、
1.『テーブルID,項目ID,レコードID,値(文字型)』
2.『テーブルID,項目ID,値属性』
の2表の定義で、何でもござれの表構成を考えてしまいます。

ただ、業務上の観点で以外で発生した区分や情報については
(例えば、更新者/更新日)は別表でも良さそうに思えますが、、、
CABed
常連さん
会議室デビュー日: 2003/06/05
投稿数: 27
お住まい・勤務地: 中央線沿線
投稿日時: 2004-07-02 11:36
区分に投票させていただきました。

CHNさんの考察に至った経緯もわからなくも無いですが、
逆に、1つのテーブルに区分と呼ばれる属性を付加することで、
今まで、2つのテーブルが必要だった情報が1つのテーブルで管理できる、
もしくは、複数の区分の情報を格納する為に、
1つのテーブル上にフィールドを多く用意する必要が無くなる。
さらに、新たな区分が増えた時にも簡単に対応できる。
・・・そんな利点もあるのではないでしょうか?

ま、ここら辺はそのテーブル自体の性格にもよると思います・・・

--
誤字修正しました


[ メッセージ編集済み 編集者: CABed 編集日時 2004-07-02 11:38 ]
あんとれ
ぬし
会議室デビュー日: 2004/01/14
投稿数: 556
投稿日時: 2004-07-02 11:55
恐らくCHNのおっしゃる区分というのは、例えば、正式顧客と一時顧客があって、
顧客テーブルに顧客区分を追加するか、正式顧客テーブルと一時顧客テーブルに分割するかというようなことだという意味だと捉えておりますが、テーブルの分割をすると、状況によってはUNION や UNION ALL が多発して後々苦労することが考えられることから、区分に投票しました。

ケース・バイ・ケースだとは思いますが・・・。
CHN
ぬし
会議室デビュー日: 2002/03/07
投稿数: 382
投稿日時: 2004-07-02 12:42
みなさん、どうもありがとうございます。

なんか、混乱させてしまいまして、
申し訳ありません。
実は何も深い意味がなく、気軽に投稿していました。

逆にこれで、最初から自分の意図をはっきりさせるよりも
沢山の角度からの意見が聞けたと思っています。
かえってよかったと思ってます。

いつもですが、私の投稿したスレッドは
質問にあった見解だけ書いてくれ、というような
考えはありません。なんでも、関係ないことでも
書いて頂いてOKです。自分は一点に集中して議論が
あまり好きではなくて、いろいろな話が聞きたいと
思っているわけです。

_________________
1

スキルアップ/キャリアアップ(JOB@IT)