2011-02-10 13 views
0

私は、データベース内のすべてのテーブルが同じフィールドと同じ値を持つデータベースを扱っています。たとえば、ほとんどすべてのテーブルにGroupIdというフィールドがあり、現在データベースには1つのグループIDしかありません。ほとんどすべてのテーブルで同じ外来キーを使用する代わりに

すべてのデータはそのフィールドに関連しているとすることにより同定することができる

  • 利点は、新しいグループが作成されると、フィールド
  • データが適切にグループのために

短所を識別されると述べた

  • すべてのテーブルには、このフィールドがあります。
  • すべてのストアド・プロシージャは、このフィールド

これは大したことによってフィルタに

  • すべてのクエリが持っているパラメータとして、このフィールドを持っている必要がありますか?このアプローチに代わるものはありますか?

    おかげ

  • +0

    解決しようとしている問題についてもう少し詳しく説明できますか?ドメイン固有の知識がなければ、これは議論のように6と6の違いと思われます。 – jwir3

    +0

    私はこれがドメイン特有の情報が必要ではないと考えています。これは多くのドメインに適用できます。それが役立つなら、あなたはグループIDを顧客IDと考えることができます。顧客に関連するすべてのデータ(グループではなく)。 –

    答えて

    0

    あなたが将来的に複数のグループによってデータを識別できるようにする必要がある場合は、外部キーを持つことは良い習慣です。しかし、それは、すべてのテーブルがこのフィールドを持つ必要があることを意味しません。グループに直接関係するテーブルのみが必要です。例えば、状態値を持つルックアップテーブルはそれを必要としないかもしれませんが、customersテーブルは可能性があります。レコードを削除しようとすると、それをすべてのテーブルに追加すると悪いことが起こる可能性があり、テーブルが579個(25個しかありません)をチェックする必要があります。これはすべて、グループの意味がどのようなものかによって大きく左右されます。ほとんどのテーブルは、特定のクライアントに関連するデータが含まれているため、さまざまなクライアントが他のクライアントのデータを参照できるようにしたくないため、クライアントテーブルとの関係があります。そのような種類のデータを含まない表はそうではありません。

    ほとんどのクエリではフィールドが必要な場合があります。多くのストアドプロシージャでは入力変数として使用したいと考えていますが、本当にこの情報をフィルタリングする必要がある場合は、そうする必要があります。

    ただし、グループが1つしかなく、複数のグループになることはありません。時間、労力、スペースの無駄です。

    +0

    なぜ私はしたいですか?これは、リレーショナル表がどのように機能するのかを示しています。 – HLGEM

    関連する問題