Это зависит немного больше от того, как структурированы фотографии и видео.Рассмотрим следующий дизайн БД:
MediaType
----------
ID *
Name
Media
----------
ID *
TypeID
OwnerName
Name
Size
Path
Photo
----------
MediaID *
MediaTypeID (constraint, always set to the photo type)
Height
Width
Video
---------
MediaID *
MediaTypeID (constraint, always set to the video type)
Rating
Если Фото и Видео имеют FK для MediaType и для Media, я бы сделал комментарии относящимися к таблице Media вместо одной, а не к фотографиям или видеостол напрямую.Это часто тот тип дизайна, который я использую, когда фото и видео имеют много общих свойств.Это особенно полезно, когда вы хотите сделать что-то вроде безопасности, потому что вам не нужно повторять одни и те же конструкции видимости и владения для каждого типа носителя, с которым вы имеете дело.Это также довольно быстрый запрос, потому что многие запросы часто ищут только общие свойства или только строки определенного типа, поэтому некоторые таблицы включать не нужно.Проектирование базы данных путем моделирования этих отношений IS-A также обеспечивает высокую избирательность ваших индексов, что означает speed .
Если вы заблокированы в своем дизайне, а основа для видео и фотографий не имеет общего "таблица », то я бы сделал отдельную таблицу комментариев для каждого.