我有一个存储产品图像元数据的数据库模式，如下所示：
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。而product_id代替entry_id，其中image_type products将成为产品ID，而图片类型users将是user_id，依此类推。
我知道这是非规范化，可能会导致问题（如果应用程序端存在错误）。但是，如果我需要新类型实体的图像来创建一组3个新表来处理同样的问题，那么这似乎是太多的开销。同样，在应用程序端也会出现（种类）代码重复。
你会建议什么？
答案 0 :(得分：1)
简短回答：不，那将使用数据库反模式 - 主要问题是缺乏参照完整性，因为不能能够在该表上定义外键。
答案很长：你想要做的是“多态关联”。有几种方法可以解决这个问题：
解决方案A）有两个可为空的列：product_id和user_id
这比仅具有entry_id更好，因为您可以定义外键。您的应用程序只需要确保image_batches表中每一行的一列（且只有一列）为NULL。
解决方案B）有两个中间表：product_image_batches和user_image_batches，每个都引用你的image_id
这将从您的应用程序中保留完整性，并将其移至您的数据库，但引入了两个新表。