テーブル定義の常識

質問

DB設計の常識について教えてください。

こんなCSVファイルをDBに取り込むとします。
（補足：個人番号だけでは主キーになりえないとします。複数の組に所属する個人がありうる）

組番号,個人番号,名前,個人番号,名前,個人番号,名前,・・・50人分繰り返し
組番号,個人番号,名前,個人番号,名前,個人番号,名前,・・・50人分繰り返し
組番号,個人番号,名前,個人番号,名前,個人番号,名前,・・・50人分繰り返し
　：
100組分繰り返し

このとき、組番号と個人番号を主キーとして
・組番号
・個人番号
・名前

という列を定義すればよいと思うのですが、こんな考え方もあるのでしょうか?
組番号を主キーとして
・組番号
・個人番号1
・名前1
・個人番号2
・名前2
・個人番号3
・名前3
　：
50人分繰り返し

つまり、CSV1行で1レコードとしてしまうということです。
（テーブルの定義が長くなりますが、レコードの件数は少なくてすむ）

上記の2パターンのうち、常識的なDB設計とはどちらでしょうか？
パフォーマンス的に有利なのはどちらでしょうか？
たいした違いは無いものなのでしょうか？
個人の好みの問題なのでしょうか？

ご意見お待ちしております。

回答No.2

noname#60992 · ベストアンサー

100組分程度のレコードであれば、とっても非力なPCを使っていない限り、利用に違いがわかるようなパフォーマンスの差はないと思いますけれど、

RDBであることを前提として考えるなら、No1さんのおっしゃっておられる、
組番号-個人番号
個人番号-名前
の２テーブルが常識。
・組番号
・個人番号
・名前
という構造は、それだけですむならこれはこれで良いと思う。

１行１レコードとしてしまうと、
一人分のレコードを変更する際や、
組の中で並び替えを行いたいとき、
性別で抽出したいとき、
個人名で検索したいとき、
その他個人に係ることもろもろの行為を行うとき、
非常にめんどくさいことになります。

読み込みがめんどくさいなら、元々あるレコードの形のまま一時的に読み込み、それを元に新しいテーブルを作られるのはありだと思います。

常識的なテーブル設計をしておけば、大体どんなことをするにしても、
テーブルを追加することで対応可能なことが多いです。
そうでないテーブル構造を使うなら、レコードに対してどのような操作を行いたいのかをすべて考えてから作らないと、手間のかかるパフォーマンスの悪いものになってしまう可能性があります。

お礼

アドバイスありがとうございます。

レコード数もやはり影響ありますか。
今回は何万件ということは無いと思いますので、パフォーマンスについては深く考えなくても良いのかな。

普通は
> 組番号-個人番号
> 個人番号-名前
> の２テーブルが常識。
ということなんですね。

レコード数的に考えても、テーブルの利用方法的に考えても、今回は普通の（教えて頂いた）テーブル構造で問題ないという感じがしてきました。

回答No.3

CHRONOS_0

>個人番号だけでは主キーになりえないとします。複数の組に所属する個人がありうる
こういう前提の場合個人と組は多対多の関係にあるとみなされますから

テーブルは
[組マスタ](組番号、組名、・・・)
[個人マスタ](個人番号、個人名、・・・)
[組み合わせ](組み番号、個人番号)
の3つにするのが定石ですね

行方向に50人並べるのは最も避けるべき構造です
このような構造では集計も検索もできません

お礼

> 行方向に50人並べるのは最も避けるべき構造です
> このような構造では集計も検索もできません
ありがとうございます。
たしかに、パフォーマンスの心配をするより前に、使い方の心配をしないといけませんでしたね。

経験者の方々のご意見を参考にさせていただきます。

回答No.1

netcatme

常識的に前者の案。
普通は、
組番号-個人番号
個人番号-名前
の二種類のテーブルを作る
パフォーマンスは、そのテーブルの利用方法による。
個人番号で検索はせず、組の人数が変化せず、組の一覧でのみ利用するのであれば、後者が当然パフォーマンスが良い（キーは組番号のみ）

お礼

アドバイスありがとうございます。

テーブルの利用方法によってパフォーマンスが違うんですね。
利用方法も書いておいたほうが的確なアドバイスがもらえたということでしょうかね。
今回は多分、組で検索する程度です。
更新はまず無いはずです。
削除は日次のバッチで数ヵ月後に消すことを考えています。