0

複数のアカウントから複数のユーザーを持つことができるアプリケーションを構築しています。たとえば、アカウントは会社 ABC である可能性があります。ユーザー X、Y、および Z は、このアカウントのメンバーです。ABC 社が新しい DB アイテムを作成した場合、ABC 社のみが表示および管理できるように、各アカウントには独自の個別のインスタンスが必要です。私の質問は次のとおりです。DB 内のすべてのテーブルで、アカウントへの明示的な外部キー参照を作成する必要がありますか? 例えば：

表 - アカウント

ACCOUNT_ID | ACCOUNT_NAME
1234       | Company ABC

表 - ページ

PAGE_ID | PAGE_TITLE | ACCOUNT_ID
987     | My Page    | 1234

表 - 資産

ASSET_ID | ASSET_TITLE | ACCOUNT_ID
4443     | My Asset    | 1234

表 - グループ

GROUP_ID | GROUP_NAME  | ACCOUNT_ID
8888     | Admins      | 1234

等？

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

4

1 に答える 1

1

私はこの状況に対処しなければなりませんでした。おそらく、多くの (必ずしもすべてではありませんが) テーブルに ACCOUNT_ID 列を含める必要があります。別の方法として、アカウントごとに個別のデータベースを用意することもできます。これは、DDL および DML へのすべての変更が普遍的に適用されるようにする必要があるため、メンテナンスの問題につながる可能性があります。また、パフォーマンスの問題が発生する可能性もあります。各テーブルに列を適用すると、クエリの結合とデータに必要なビューが (わずかに) 複雑になりますが、結合は一般に、パフォーマンスとスペースの点で低コスト (またはゼロ) です。個別のデータベースの利点の 1 つは、より安全なソリューションになる可能性が高いことです。つまり、各アカウントを他のすべてのアカウントからリング フェンシングします。

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

編集:このタイプの設計上の質問に関する 私の質問とその回答とコメントは、上記の結論につながりました。

于 2011-03-15T14:21:49.510 に答える