- PR -

テーブルの構成（リレーション）について

«前のページへ 1|2
投稿者投稿内容
るぷ犬
常連さん
会議室デビュー日: 2004/11/10
投稿数: 46
投稿日時: 2007-01-16 16:26
ご返答頂いた方、ありがとうございました。


業務を知るものに聞いたところ、
兼務することは無く、複雑になるものでもないという事なので、
上記Ａにしようと思います。


いつも、何を持ってどの形が最適なのかを悩んでしまいますが
今回、いろいろと答えてくださった方々、ありがとうございました。
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2007-01-17 00:08
引用:

るぷ犬さんの書き込み (2007-01-16 16:26) より:
業務を知るものに聞いたところ、
兼務することは無く、複雑になるものでもないという事なので、
上記Ａにしようと思います。


仕様変更なしに無事に終わるといいですね。
自分なら後々に柔軟に対応可能なBを選びます。

＃要件を策定する側から念書が取れれば別ですけど。
＃少なくともそのような柔軟性がない仕様は嫌がります。
＃まぁ、システムのほんの枝葉な部分ならどうでもいいです。

常識的に考えて社員は一般的に組織に所属するのであって、
セクションに直接に所属しているわけではないですので。

＃契約社員などでは異なることもあるかもしれませんが。

普通は「部課にアサインされている」と考えるのでは？
その構造では取締役などの表現に無理があると思います。

引用:

Tasukuさんの書き込み (2007-01-16 11:53) より:
ただ、検索パフォーマンスを優先したいといった別の要件があって、
A: が B: より優れているという実証ができているなら、A: もありだと思います。
（本来はそういう設計ポリシーを決めておくべきなんですが...）


パフォーマンスを理由にした非正規化と称した手抜きなのでは？
本当にそれが理由な非正規化は滅多に見ないので疑わしいです。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2007-01-17 00:41
私も所属テーブルだのの関連テーブルでリレーションを表現しますね。
テーブル間の依存関係が疎結合になって、
仕様変更に柔軟に対応しやすくなります。

この辺は、設計技法がたくさんあって、
必ずどれかが正解というわけではありませんが、
自分の経験則では開発しやすいという認識です。

パフォーマンスの問題の話も出ていますが、
例えばパフォーマンスを改善するには
極端な話CPUやらメモリを足せばどうにかなります。

仕様変更に強いデータ構造の場合、
動作中のアプリケーションに対する影響が最小限に抑えられます。
仕様変更のコストが抑えられるわけです。

この辺も正解があるわけではないのですが、
私は「業務システムの仕様なんてコロコロ変わって当然」と割り切っています。
Tasuku
大ベテラン
会議室デビュー日: 2006/09/14
投稿数: 106
お住まい・勤務地: tokyo
投稿日時: 2007-01-17 10:05
引用:

あしゅさんの書き込み (2007-01-17 00:08) より:
引用:

Tasukuさんの書き込み (2007-01-16 11:53) より:
ただ、検索パフォーマンスを優先したいといった別の要件があって、
A: が B: より優れているという実証ができているなら、A: もありだと思います。
（本来はそういう設計ポリシーを決めておくべきなんですが...）

パフォーマンスを理由にした非正規化と称した手抜きなのでは？
本当にそれが理由な非正規化は滅多に見ないので疑わしいです。


私も A: を手放しで推奨しているつもりはありません。

「滅多に見ない」かどうかという頻度の問題は、
その人の担当している業務領域・経験に依存しますよね。
それを一般化するのはおかしいと思いますし、
それを根拠に「やる・やらない」を議論するのもおかしな話だと思います。

「あるか・ないか」で言えば、「あり得る」と書いたまでの話で、
その判断は必要性に基づいて行えばよい話でしょう。

実証せずに非正規化するなら「手抜き」ですが、
実証した上での選択なら「手抜き」だとは思いません。
とんくま
ベテラン
会議室デビュー日: 2005/08/02
投稿数: 56
お住まい・勤務地: 東京
投稿日時: 2007-01-19 16:05
引用:


概念としましては、

会社テーブルには複数の会社が入り（複数レコード）、
その複数の会社のそれぞれの部課が部課テーブルに入ります。

部課テーブルについては、部課は同じ部署名（システム部など）がありますが、
それは会社ＩＤで、分別しようとしています。


また、社員テーブルにはどの会社の、どの部課の人間であるかという情報が必要です。
（通常、社員はひとつの会社、ひとつの部課にしか属していません）



社員テーブルに会社ＩＤが入っていない理由は下記のように、


社員ＩＤより、会社名、部課名、氏名を抽出したい場合、
３つのテーブルを結合すればデータは取得できると考えた為でした。


社員テーブルと部課テーブルを結合した場合、結合条件は部課ＩＤになるでしょうから結果は、（他社にも同じ部課ＩＤがあるかもしれませんので）その他社の部課も結合されるでしょう。これに会社テーブルを結合すると（今の設計では）同じ部課ＩＤを持った他社も結合されるので、
社員テーブルに、会社ＩＤは必須と思います。

引用:

しかし、社員ＩＤより、会社名、氏名を抽出したい場合も
３つのテーブルを結合するようになり（ますよね？）、
（部課テーブルも結合しないといけない（はず））
というところで、


果たして、

Ａ：社員テーブルにも会社ＩＤを付ける
Ｂ：常に３つのテーブルを結合する


の、どちらかがいいのかという所で迷っています。



前記の理由で、Ａを取らざるを得ないと思います。

[ メッセージ編集済み 編集者: とんくま 編集日時 2007-01-19 16:07 ]
カーニー
ぬし
会議室デビュー日: 2003/09/04
投稿数: 358
お住まい・勤務地: 東京
投稿日時: 2007-01-19 21:21
引用:

とんくまさんの書き込み (2007-01-19 16:05) より:
社員テーブルと部課テーブルを結合した場合、結合条件は部課ＩＤになるでしょうから結果は、（他社にも同じ部課ＩＤがあるかもしれませんので）その他社の部課も結合されるでしょう。これに会社テーブルを結合すると（今の設計では）同じ部課ＩＤを持った他社も結合されるので、
社員テーブルに、会社ＩＤは必須と思います。


最初の書き込みによると、そうでもないようです。

引用:

○TBL_部課

部課ＩＤ PK
会社ＩＤ
部課名


部課IDが単独で主キーですから、会社が異なっても部課IDが重複することはありません。
よくある代理キーということなんでしょう。
«前のページへ 1|2

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