3

たくさんのフィールドを持つテーブルがあります。フィールドは、ジョブのプロジェクト マネージャー情報のように、論理的なグループに分割できます。グループ自体は、独自の PK を持たず、持つべきではないため、実際にはエンティティ候補ではありません。

今のところ、それらをグループ化するために、フィールドにはプレフィックス (たとえば PmFirstName) がありますが、メイン テーブルで 1:1 の関係を持つ複数のテーブルに分割することを検討しています。

これを行う際に注意すべきことはありますか？これは単に悪い選択ですか？

追加のすべての結合でクエリがより複雑になる可能性があることがわかりますが、それはビューで軽減できますか? 100k レコード未満のテーブルについて話している場合、これはパフォーマンスに顕著な影響を与えるでしょうか?

編集:非実体候補の考えをもう少し正当化します。この情報は、ユーザー ベースによって入力されます。彼らはお互いを知りません/気にしません。したがって、同じユーザーが同じ「projectManager 名」またはこの時点で制約に違反していないものを送信する可能性があります。別のユーザーからのエントリを相互に関連付ける必要があるかどうかは、後でパイプラインで判断する必要があります。これらのものに独自のキーを与えると、メインテーブルが成長するのと同じ速度で成長します-それらは本質的に同じエンティティの一部であるため. ユーザーが利用可能な「プロジェクト マネージャー」のリストから選択することはありません。

したがって、上記を考えると、それらはエンティティではないと思います。しかし、そうではないかもしれません。さらに考えがある場合は、投稿してください。

4

5 に答える 5

4

特定のパフォーマンス上の理由がない限り、通常は 1 対 1 の関係を使用しません。たとえば、使用頻度の低い大きなテキストまたは BLOB タイプのフィールドを別のテーブルに格納します。

しかし、ここで何か他のことが起こっているのではないかと思います。あなたが与える例-PmFirstName-では、「ProjectManagers」または「Employees」テーブルに関連する単一のpm_idが必要なようです。これらのグループのどれも実際にエンティティ候補ではないということですか?

于 2009-02-27T20:03:28.747 に答える
2

私には、余分な列に興味がない行やクエリがない限り、匂いがします。たとえば、クエリの大部分で PmFirstName 列を選択していない場合、または行の大部分のサブセットでそれらの列が NULL である場合です。

匂いタグが好きです。

于 2009-02-27T20:00:54.370 に答える
2

継承に似た構造には 1 対 1 の関係を使用します。

たとえば、すべての債券には、CUSIP、Coupon、DatedDate、および MaturityDate などの基本的な情報があります。これはすべてメインテーブルに入ります。

現在、債券の各タイプ (Treasury、Corporate、Muni、Agency など) には、独自の列のセットもあります。

以前は、すべての情報を含む 1 つの信じられないほど広いテーブルしかありませんでした。ここで、型固有の情報を個別のテーブルに分割することで、パフォーマンスが大幅に向上します。

今のところ、それらをグループ化するために、フィールドにはプレフィックス (たとえば PmFirstName) がありますが、メイン テーブルで 1:1 の関係を持つ複数のテーブルに分割することを検討しています。

person テーブルを作成します。すべてのデータベースでこれが必要です。次に、プロジェクト テーブルに、人物テーブルを指す PMKey という列があります。

于 2009-02-27T20:08:12.763 に答える
0

フィールドのグループがエンティティ候補ではないと感じるのはなぜですか? そうでない場合、プレフィックスでそれらを識別しようとするのはなぜですか?

プレフィックスを削除するか、独自のテーブルに抽出します。

于 2009-02-27T20:02:21.277 に答える
0

それらが別の場所で使用できる別個の論理エンティティである場合、それらを別個のテーブルに分割することは価値があります。

そのため、「プロジェクト マネージャー」は現在すべてのプロジェクトに対して 1 対 1 である可能性がありますが、後でプロジェクト マネージャーに複数のプロジェクトを持たせたい場合があります。だから余分なテーブルを持つことは良いことです。

PrimaryFirstName、PrimaryLastName、PrimaryPhone、SecondaryFirstName、SecondaryLastName、SECondaryPhone がある場合

FirstName、LastName、Phone を含む "Person" テーブルを作成できます。

次に、元のテーブルには、以前の 6 つの列を置き換えるために "PrimaryId" 列と "SecondaryId" 列のみが必要です。

また、SQL を使用すると、ファイル グループとテーブルを複数の物理的な場所に分割できます。したがって、1 対 1 の関係を持つ POST テーブルと COMMENT テーブルを持つことができますが、COMMENT テーブルは別のファイル グループと、より多くのメモリを備えた別の物理ドライブにあります。

1:1 は常に匂いがするわけではありません。目的がなければ。

于 2009-02-27T20:09:02.090 に答える