0

製品画像のメタデータを格納するデータベース スキーマがあり、次のようになります。

image_sizes (this is purely metadata - what sizes to create of given image, eg "thumb", "main image", "sidebar widget icon of the product", etc):
image_size_id (auto-increment, pk)
name (thumb, main)
max_width
max_height
crop (flag, to crop or just resize to fit)

images table:
image_id (auto-increment, pk)
image_size_id (fk to image_sizes)
image_batch_id (fk to batches, when there is uploaded image for the product, an image is created for each product size, all the images have same batch_id, described below)
location (relative path to the project eg uploads/products/thumbs)
width (result after processing, in pixels
height (result after processing, in pixels)
size (in bytes)

image_batches tables:
image_batch_id (auto-increment, pk)
product_id (fk, to which product it belongs)
original_filename (eg the file was called 123.jpg when uploaded)
is_default (if the product 10 images, one is default)

したがって、このスキーマを使用すると、たとえば製品のすべての「サムネイル」を取得して表示できます。ここでの問題は、アプリケーションでユーザーまたは他のエンティティ (会場も言うことができます) に対して同じスキーマを持ちたいということです。

次のようにスキーマを次のように変更すると適切でしょうか。

image_batches追加の列がありますimage_type_id。image_type、products、usersがありますeverything else that needs images。また、image_typeが製品 ID になる代わりにproduct_id、 image typeが user_id などになります。entry_idproductsusers

これが問題を引き起こす可能性のある非正規化であることはわかっています (アプリケーション側にバグがある場合)。しかし、同じ問題を処理するために 3 つの新しいテーブルのセットを作成するために新しいタイプのエンティティの画像が必要な場合、オーバーヘッドが多すぎるようです。また、そのようにすると、アプリケーション側でも (一種の) コードの重複が発生します。

何を提案しますか？

4

1 に答える 1

1

簡単な答え: いいえ、それはデータベースのアンチパターンを使用することになります。主な問題は、そのテーブルで外部キーを定義できないため、参照整合性の欠如です。

長い答え: やりたいことの名前は「ポリモーフィック アソシエーション」です。これにはいくつかのアプローチがあります。

解決策 A) 2 つの null 可能な列がある: product_id と user_id

外部キーを定義できるため、単に entry_id を使用するよりも優れています。アプリケーションは、image_batches テーブルのすべての行に対して、これらの列の 1 つ (および 1 つだけ) が NULL であることを確認するだけで済みます。

解決策 B) 2 つの中間テーブルがあります: product_image_batches と user_image_batches で、それぞれが image_id を参照します。

これにより、アプリケーションの整合性を維持する負担が軽減され、アプリケーションがデータベースに移動されますが、2 つの新しいテーブルが導入されます。

于 2013-02-24T20:14:46.677 に答える