| |
▼小僧 さん：
こんばんは。返信ありがとうございます。
>ご質問の内容は「テーブルの正規化」という事ですね。
>Web で検索すると色々出てきますので参照してみて下さい。
正規化についてはMS社他のwebでの例題ではなんとなくわかるのですが
自分のテーブルで考えると難しいです(ToT）
一応、T家族、T銀行、T支店、T地区のようにIDを別につけられるものは
出来るだけ分けています。
それでもT会員のフィールドが多いです。
>例えば会社の同僚の住所録テーブルを作成するとすると、
>会社の情報（社員コード、部署、役職など）と
>プライベートな情報（血液型、住所、電話番号など）は別テーブルになります。
この場合は、両方に社員コードを持つと考えて良いのでしょうか？
ちょっと意味合いは違いますが、今回の質問もちょっと似ている？
と（何となく）思います。
>1つのテーブルに全ての情報を持たせてしまうと、
>その人の会社に関するデータを更新したくても
>全てのデータを引っ張ってきてしまうので、
>あまり効率的ではありません。
似たような思いからテーブルを分けてみようかなと思ったわけです。
が、webで見た例題でも今回の質問のように
テーブル1 ID ------ テーブル2 ID
テーブル1 ID ------ テーブル3 ID
テーブル1 ID ------ テーブル3 ID
と一つのIDでいくつものテーブルとつなげているものが見当たりませんでした。
他にもT会員とリレーションで結んでいるものがあるので、実際にはもっと
増えます。
webの例題であまり見かけないことなので、同じIDをそれぞれにもたせて
テーブルを分割する方法はどうなのか？（まずいのか？）という思いから
質問をさせていただきました。
一つのIDでいくつものテーブルとつなげるというのはテーブル作成を行う上では
あまりない事なのでしょうか？
>逆に「社員番号xxxxのデータを全て見たい」などの場合には
>同じIDで結び付けられた社員をテーブル毎に参照しにいくので
>この場合は1つの大きなテーブルがあった方が効率が良くなります。
これは選択クエリで全部参照してしまうという方法で解決できないものなの
でしょうか？
>適度（これが一番難しいですよね…）な所まで正規化を進めていきましょう。
難しいです。正規化。きっとまだ良く理解していないのだ思います。
|
|
buti
- 05/7/6(水) 22:25 -
