базы данных (де) нормализация - таблица с изображениями для различных объектов

Question

у меня есть схемы базы данных, которая хранит метаданные изображения продукта и выглядит следующим образом:

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, который для образа_type products будет идентификатором продукта, для типа изображения users будет user_id и так далее.

Я знаю, что это денормализация, которая может привести к проблемам (если на стороне приложения есть ошибка). Но мне кажется, что слишком много накладных расходов, если мне нужны изображения для нового типа сущности, чтобы создать набор из трех новых таблиц для решения одной и той же проблемы. Также этот способ будет (вид) дублирования кода на стороне приложения.

Что вы предложите?

Answer 1

Краткий ответ: Нет, это будет использовать антипаттерн базы данных - основная проблема заключается в отсутствии ссылочной целостности, поскольку вы не сможете определить внешние ключи в этой таблице.

Длинный ответ: название того, что вы хотите сделать, это «полиморфная ассоциация». Есть несколько подходов к этому:

раствор А) две NULLABLE колонки: PRODUCT_ID и user_id

Это лучше, чем просто имея entry_id, потому что вы можете определить внешние ключи. Ваше приложение должно гарантировать, что один (и только один) из этих столбцов имеет значение NULL для каждой строки в таблице image_batches.

Раствор B) имеют две промежуточные таблицы: product_image_batches и user_image_batches которых каждая ссылка ваш image_id

Это будет принимать Burdon поддержания integrety от вашего приложения, и переместить его в базу данных, но вводит две новые таблицы ,