1

次のシナリオがあるとします。

Artist ==< Album ==< Track
//ie, One Artist can have many albums, and one album can have many tracks

この場合、3 つのエンティティすべてに基本的に同じフィールドがあります。

  • ID
  • 名前
  • 対応する子 (Artist to Album および Album to Track) に対する 1 対多の関係の外部

提供されたソリューションの典型的なソリューションは、同じフィールド (ArtistID、AlbumID など) と 1 対多の関係フィールドの外部キー制約を持つ 3 つのテーブルです。

しかし、この場合、同じフィールドの繰り返しを避けるために継承の形式を組み込むことはできますか? 私は次のようなことを話している：

Table: EntityType(EntityTypeID, EntityName)
       This table would hold 3 entities (1. Artist, 2. Album, 3. Track)

Table: Entities(EntityID, Name, RelField, EntityTypeID)
       This table will hold the name of the entity (like the name of 
       an artist for example), the one-many field (foreign-key
       of EntityID) and EntityTypeID holding 1 for Artist, 2 for Album 
       and so on.

上記のデザインについてどう思いますか？この DB シナリオに「OOP の概念」を組み込むことは理にかなっていますか?

そして最後に、最初のシナリオの外部キー制約を使用することを好みますか、それともより一般的なシナリオを使用することをお勧めしますか?アルバム）アプローチ？

..ところで、考えてみると、Artist の RelField の入力値が Album に対応しているかどうかをトリガーで実際に確認できると思いますか?

4

6 に答える 6

5

私は最近、まさにこの抽象化の考え方が一貫して実装されているのを見てきました。アプリケーションとそのデータベースは、保守とトラブルシューティングが非常に困難になっています。私はこのテクニックから離れます。シンプルであるほど良い、というのが私のモットーです。

于 2009-04-08T03:14:53.450 に答える
2

さまざまなエンティティに必然的に蓄積される追加のフィールドが義務付けられる可能性はほとんどありません。合理的に近い方法で現実を反映しないことによって得られるものは何もありません。

通常の OO 設計でこれらのエンティティを混同する可能性は低いと思います。

これは、1 つのテーブル (「エンティティ」という名前) に別のテーブル (「属性」という名前) とそれらの間のジャンクション テーブルを実装するために一度見た試みを (ほんの少しだけ) 思い起こさせます。

于 2009-04-08T03:13:06.310 に答える
1

3 つすべてをくっつけると、クエリが読みにくくなり (3 つのカテゴリをビューとして分解しない限り)、検索とインデックス作成がより困難になります。

さらに、ある時点で、他のカテゴリの属性ではない属性を 1 つのカテゴリに追加する必要があります。3つすべてを一緒に固執すると、システムのチャンクを取り除かない限り、変更の余地がなくなります.

つまずくほど賢くならないように。

于 2009-04-08T03:17:27.127 に答える
1

あなたのOOPの方法でそれを行うことの唯一の利点は、将来追加される他の要素タイプがある場合です（つまり、アーティスト、アルバム、トラック以外）。その場合、スキーマの変更は必要ありません。

ただし、私は OOP 以外の方法を選択する傾向があり、その場合はスキーマを変更するだけです。OOP ソリューションで発生するいくつかの問題は次のとおりです。

  • アーティストの生年月日を追加したい場合は？
  • アルバムやトラックの長さを保存したい場合はどうしますか?
  • トラックタイプを保存したい場合はどうなりますか?

基本的に、要素タイプの 1 つまたは 2 つだけに限定されたものを格納したい場合はどうすればよいでしょうか?

于 2009-04-08T03:17:43.663 に答える
1

この種のことに興味がある場合は、PostgreSQLでのテーブルの継承をご覧ください。

create table Artist (id integer not null primary key, name varchar(50));
create table Album (parent integer foreign key (id) references Artist) inherits (Artist);
create table Track (parent integer foreign key (id) references Album) inherits (Artist);
于 2009-04-08T03:28:25.913 に答える
0

基本エンティティ (ID、名前) の概念からいくらか再利用できるかもしれませんが、それを超えると、アーティスト、アルバム、およびトラックの概念が分岐します。

そして、より現実的なモデルでは、複数のアーティストがアルバムの 1 つのトラックに貢献している可能性があるという事実に対処する必要があるでしょう...

于 2009-04-08T03:16:05.837 に答える