Database (de)normalization - table with images for different entities

Question

I have a database schema which stores product images metadata and looks like this:

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)

So this schema allows me to get all the "thumbnails" for a product for example and show them. Now the problem is that I want to have same schema for the users, or for other entities (there will be lets say venues as well) in the application.

Would it be appropriate if I modify the schema bellow, so that:

image_batches have additional column image_type_id. There will be image_type for products, users, everything else that needs images. And instead of product_id to have entry_id which for image_type products will be the product id, for image type users will be the user_id and so on.

I know this is denormalization that could lead to problems (if there is bug on the application side). But it seems like too much overhead if I need images for new type of entity to create set of 3 new tables to handle the same problem. Also that way there will be (kind of) code duplication on the application side as well.

What would you suggest?

Answer 1

Short answer: No, that would be using an database antipattern - the main problem being the lack of referential integrity, because you won't be able to define foreign keys on that table.

Long answer: The name of what you want to do is "polymorphic association". There are a few approaches to this:

Solution A) have two nullable columns: product_id and user_id

That is better than just having an entry_id, because you can define foreign keys. Your application only has to ensure that one (and only one) of those columns is NULL for every row in the image_batches table.

Solution B) have two intermediate tables: product_image_batches and user_image_batches which each reference your image_id

This will take the burdon of maintaining integrety off your application, and move it to your database, but introduces two new tables.