0

別のレコードを参照する必要があるが、同じテーブルのテーブルがあります。次に例を示します。

Customer
********
ID
ManagerID (the ID of another customer)
...

私はこれをするのが悪いと感じています。私のもう 1 つのアイデアは、関係を格納した別のテーブルを用意することでした。

CustomerRelationship
***************
ID
CustomerID
ManagerID

このような些細なことを複雑にしすぎているかもしれませんが、この特定のシナリオに最適なアプローチについていくつかのアイデアを得たいと思いますか?

ありがとう。

4

8 に答える 8

3

最初のデザインには何の問題もありません。2つ目は、「中間」テーブルがあり、多対多の関係に使用されますが、これはあなたのものではないと思います。

ところで、その中間テーブルには、それ自体のIDはありません。

于 2009-08-25T23:00:55.370 に答える
2

なぜあなたはこれについて「悪い気持ち」を持っているのですか？テーブルがそれ自体の主キーを参照することは完全に許容されます。セカンダリテーブルを導入すると、クエリの複雑さが増すだけで、パフォーマンスに悪影響を及ぼします。

于 2009-08-25T23:01:28.893 に答える
2

顧客は複数のマネージャーを持つことができますか？その場合は、別のテーブルが必要です。それ以外の場合は、単一のテーブルで問題ありません。

于 2009-08-25T23:01:44.150 に答える
2

最初のアプローチを使用できます。自己結合の使用も参照してください。

于 2009-08-25T23:03:23.180 に答える
2

最初のアプローチにはまったく問題はありません。実際、オラクルは、このタイプの階層構造を直接サポートすることを目的としたバージョン6以降、SQLに「CONNECTBY」拡張機能を組み込んでいます。これをたくさん行う予定です）。

類似したものがないデータベースに自己結合する必要がありますが、それは完全に優れた標準的なソリューションでもあります。

于 2009-08-25T23:05:37.403 に答える
0

プログラマーとして、私は最初のアプローチが好きです。テーブルの数を減らしたいです。ここでは、正規化についても話していません。なぜもっと多くのテーブルが必要なのですか？それは私だけです。

于 2009-08-25T22:59:52.393 に答える
0

ここでKISSの原則に従ってください：それを単純にしてください（愚かな|愚かな|スタッド| [あなたが好むSで始まるどんな形容詞でも]）。さらに必要な理由がない限り、1つのテーブルを使用してください。

1対多/多対多の関係が当てはまる場合は、既存の列を独自のテーブルに抽出し、その時点で新しいエントリを入力できることに注意してください。

于 2009-08-25T23:04:23.630 に答える
0

このような自己参照テーブルを避けることをお勧めする唯一の理由は、SQL Server には自己参照テーブルに制限がある場所がいくつかあるからです。

たとえば、インデックス付きビューが必要になった場合、ビュー定義で使用されているテーブルの 1 つが実際に自己参照している場合、クラスター化されたビューを作成できないことがわかります。ビューのインデックス:-(

しかし、それとは別に - デザイン自体は健全で絶対に有効です - 頑張ってください! 私は常に物事を可能な限りシンプルに保ちたいと思っています (ただし、それ以上にシンプルにすることはできません)。

マルク

于 2009-08-26T05:08:42.853 に答える