2

私が開発した Web サイトは、stackoverflow のような構造になっています。データベースにPostsテーブルとPostImagesテーブルがあります。テーブルは次のPostImagesようになります。

PostImageId PK
PostId      FK
Uri
MimeType

そのため、投稿には多くの画像が関連付けられている可能性があります。

私は現在、サイトの他の場所に画像を含める必要があるという要件があります。Usersプロファイルに画像をCategories含めることができ、画像を含めることができ、画像をAddresses含めることができる必要があります。

Imagesデータベースにはテーブルを1 つだけ持つのが最善のようです。これをどのようにモデル化すればよいですか？次のような単一のテーブルを作成できます。

ImageId    PK
PostId     FK
CategoryId FK
AddressId  FK
UserId     FK
Uri
MimeType

1 つのimagesテーブルを作成してから、オブジェクトの種類ごとに追加のテーブルを作成できます。

PostImageId      PK FK
PostId           FK

CategoryImageId  PK FK
CategoryId       FK

(各アイテムの PK は、テーブルからのイメージへの FK でもありImagesます)

他にもいくつかの戦略があります。たとえば、___Imagesタイプごとにテーブルを作成し、共有Imagesテーブルを作成しないようにすることができます。それぞれに多対多のマッピング テーブルを用意することもできますが、思いもよらなかった解決策が他にもあるかもしれません。

ベストは何ですか？データベースの設計についてはよくわかりません。最も柔軟で使いやすいのはどれですか?

4

2 に答える 2

1

実際のプロジェクトでは、データベースはデータのアクセシビリティのコストを考慮して設計されています。テーブルを設計する 2 つの方法について言及しました。どちらも正しいです。すべてのフィールドを 1 つのテーブルに配置すると、データの冗長性が生じます。テーブルを2つ作っておけば問題ありません。

ただし、2 つのテーブルを結合するとコストが高くなることを覚えておく必要があります。そのため、サーバーからデータをフェッチしている間、これによりページが遅くなる可能性があります (同時に多くのユーザーが同時に試行した場合)。

一方、1 つのフィールドに配置すると、データベースでより多くのメモリが必要になりますが、データ フェッチのコストは少なくなります。選択はあなた次第です。

于 2012-11-08T12:05:46.247 に答える
1

私は2番目の選択肢に行きました。私はImagesテーブルを持っています：

Images
    ImageId    PK
    Name
    Uri
    Width
    Height
    MimeType

およびいくつかのマッピング テーブル:

PostImages
    PostImageId      PK FK
    PostId           FK

CategoryImages
    CategoryImageId  PK FK
    CategoryId       FK

テーブルを変更せずにマッピングテーブルを追加できるため、このソリューションを好みImagesます。メンテナンスが容易です。また、Imagesテーブルには画像に関するデータのみが含まれるため、テーブルをより意味のあるものにすることができます。

どのクエリでも少数の画像しか返さないため、結合のコストは大きな問題ではありません。ただし、2 つの方法の相対速度はテストしていません。

于 2013-05-03T16:58:21.327 に答える