2011-03-14 12 views
0

複数のアカウントから複数のユーザーを持つことができるアプリケーションを構築しています。たとえば、アカウントは会社ABCです。ユーザーX、Y、およびZはこのアカウントのメンバーです。会社ABCが新しいDB項目を作成する場合は、会社ABCのみが表示および管理できるように、各アカウントには別々のインスタンスが必要です。私の質問はこれです:私は私のDB内のすべての単一のテーブル内のアカウントへの明示的な外部キー参照を行う必要がありますか?たとえば、次のようにSQLで複数のアカウントとユーザーを管理する、アカウントに関連付けられた資産を管理する

TABLE -

ACCOUNT_ID | ACCOUNT_NAME 
1234  | Company ABC 

TABLEアカウント - PAGES

PAGE_ID | PAGE_TITLE | ACCOUNT_ID 
987  | My Page | 1234 

TABLE - 資産

ASSET_ID | ASSET_TITLE | ACCOUNT_ID 
4443  | My Asset | 1234 

TABLE - グループ

GROUP_ID | GROUP_NAME | ACCOUNT_ID 
8888  | Admins  | 1234 

など

これは何らかの理由で私に間違っているように見え、私は考えていないよりよい方法があるように感じます。私はこれを行うために必要なテーブルが75近くあります。これは正しいですか?

+0

1対多の関係の場合、リンクする最も簡単な方法は、アカウントIDを子テーブルに追加することです。 –

答えて

1

私はこのような状況に対処しなければならなかったので、多くの(必ずしもすべてではないが)テーブルにACCOUNT_ID列を含める必要があります。別の方法としては、アカウントごとに個別のデータベースを用意することです。これにより、DDLとDMLに対するすべての変更が普遍的に適用されることを保証する必要があるため、保守上の問題が発生する可能性があります。また、パフォーマンス上の問題が発生する可能性もあります。各表に列を適用すると、問合せ結合とデータに必要なビューが(少し)複雑になりますが、一般にジョインはパフォーマンスと領域の点でコストがかかりません。別々のデータベースの利点の1つは、より安全なソリューションである可能性が高いことです。これは、他のすべてのアカウントから各アカウントを呼び出すことです。

テーブルのすべてにアカウント列が必要というわけではありません。これの必要性はアクセス・パスに依存します。 - たとえば、テーブルにサブ/スーパータイプの関係があるとします。各サブタイプと各スーパータイプにはそれぞれ独自のテーブルがあります。すべてのサブタイプへのアクセスはスーパータイプを介してのみ行われるため、スーパータイプはACCOUNTSへの参照が必要ですが、サブタイプは参照されません。

EDIT:私の上記の結論に至った設計質問のこのタイプに関するその上 My questionと回答やコメント、。

+0

Chrisに感謝します。あなたの回答と元の質問は非常に有効で、私が選んだ方向性を確認しました。 – Freddie

関連する問題