0

シナリオ

3 つのデータベース テーブルがあります。1 つは画像用で、残りの 2 つは人物と場所用です。一人一人が多くのイメージを持つことができ、それぞれの場所が多くのイメージを持つことができるので、私は場所とイメージだけでなく、人とイメージも ONE TO MANY の関係にしたいと考えています。

質問

外部キーは主キーと同じ名前にする必要がありますか? または、「PKTableID」など、画像テーブルの外部キーを一般的なものと呼ぶことは可能ですか。このようにして、必要な画像テーブルは 1 つだけです。

大変助かります。

よろしく、

編集：

イメージ テーブルを 1 つだけにしたい理由は、各イメージが他の 1 つのテーブルのみを参照するためです。これと同様に、ここでは 2 つのテーブルの例を使用しました。実際に使用するデータベースには 20 個のテーブルがあるため、20 個の 1 対多の関係に対して SINGLE IMAGE TABLE を使用できるかどうかを知りたかったのです。 ?

4

5 に答える 5

5

編集

1 つのイメージが 20 のテーブルの 1 つだけによって所有されている場合、この設計は機能する可能性があります。

People (PersonId, Name)
Places (PlaceId, Name)
Dogs (DogId, Breed)
Doors (DoorId, Height, Width)
Images (ImageId, ImageBinary, OwnerId, OwnerTable)

OwnerTable は、OwnerId が属するテーブルの名前またはコードです。

これにより、イメージ テーブルで 20 個の FK、または 20 個の関連付けテーブルを節約できます。次に、結合で、結合先のテーブルに応じて、OwnerTable を指定します。

Id には変換可能な型 (TINYINT、SMALLINT、INT など) を使用する必要があり、できればすべてに対して 1 つの型 (INT など) を使用する必要があり、トリガーやその他のコードを使用して参照整合性を自分で管理する必要があります。

/編集

3 つではなく、5 つのテーブルが必要です。

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary)
ImagesPeople (ImageId, PersonId)
ImagesPlaces (ImageId, PlaceId)

フィールドは好きなように呼び出すことができます。People.Id、ImagesPeople.PersonId など。

しかし、あなたができないことは次のようなものです：

People (PersonId, Name)
Places (PlaceId, Name)
Images (ImageId, ImageBinary, PlaceOrPersonId)

できますが、データベースは関係を強化するのに役立ちませんし、FK がどのテーブルに属しているかを教えてくれません。どうやって知る？ID のインクリメントをずらしたり、イメージにタイプ列を追加したり、GUID を使用したりするなど、ハック的な回避策があります。

または:

Things (ThingId PK, Type)
People (ThingId PK/FK, Name, Age)
Places (ThingId PK/FK, Name, LatLon)
Images (ImageId PK, ImageBinary, ThingId FK)

画像を「モノ」にすることもできます。たまにこういうデザインを見かけます。参照整合性は提供されますが、型の排他性は提供されません。People、Places、および Images で同じ ThingId を持つことができ、データベースは気にしません。そのルールを自分でコーディングする必要があります。

編集: Cylon Cat の提案で、シナリオ 4:

People (PersonId, Name)
Places (PlaceId, Name)
PeopleImages (PeopleImageId, ImageBinary)
PlaceImages (PlaceImageId, ImageBinary)

ここでは、画像は 1 人の人物または場所によって独占的に所有されています。バージョン 2 に似ていますが、外部キーが宣言されています。必要な結合が少ないため、5 つのテーブル設計よりもパフォーマンスが向上する場合があります。「PeopleImage」と「PlaceImage」に置き換えられた、別個のエンティティとしての「Image」を失います。

于 2009-10-26T00:55:35.657 に答える
1

ピーターが指摘したように、画像を 1 人だけの写真に制限したい場合を除き、実際には多対多の関係が必要です。また、適切な場所のインデックスは地名の階層的な性質を反映します (モンマルトル、パリ、フランス = 3 つ可能) 1 つの場所の名前)。

技術的には、予約語ではなく、まだ使用されていない任意のインデックスとテーブルを呼び出すことができます。X、Y、Z12345、および WOBBLY はすべて、インデックスの有効な名前です。

ただし、実際には、何を何のために保存するかを示す命名規則に従うのが最善です。したがって、テーブル PEOPLE_X_IMAGES と PLACES_X_IMAGES は、あなたの場合には良い考えです。実際の画像テーブルの人や場所については何も必要ありません。同様に、PEOPLE テーブルと PLACES テーブルの画像については何も必要ありません。

于 2009-10-26T01:29:35.527 に答える
1

理論的には、画像テーブルに 2 つの外部キーを追加できます。1 つは人物用、もう 1 つは場所用です。次に、クエリの実行時に null を許可し、適切な列に結合できます。14 個のテーブルを結合する必要がある場合、このテーブルはどのように見えるのでしょうか。

GUID を使用しない場合は、次に理解しなければならない人のために多対多に設定することをお勧めします。

于 2009-10-26T13:08:06.490 に答える
0

どうですか

Person (PersonId PK, Name, ImageId FK)
Image (ImageId PK, Name)
Place (PlaceId PK, Name, ImageId FK)
于 2009-10-26T14:24:19.437 に答える
0

1 つのテーブルを使用できますが、リレーションシップには 20 の異なるフィールドが必要になります。外部キー関係を設定する場合、すべてのデータは親テーブルに関連付ける必要があります。1 つのテーブルに 2 つの外部キー関係を格納することはできません。したがって、必要な fk ごとに列を設定する必要があります。

于 2009-10-26T13:06:31.543 に答える