База данных: несколько таблиц или только одна таблица?

Почему бы не иметь только одну таблицу комментариев? Есть ли разница между комментарием к видео или фото? Если нет, у вас должен быть только столбец, содержащий внешний ключ для видео/фото, на который указывает комментарий, и дополнительный столбец с типом ENUM, который содержит информацию о типе ресурса, для которого предназначен комментарий.

Использование ENUM позволит выполнять ваши запросы очень быстро (поскольку сохраняется как число) и упрощает использование строки в вашем запросе.

Если у вас действительно есть две отдельные таблицы данных photos и videos, я всегда предпочитаю использовать две отдельные таблицы комментариев.

Почему?

Если вы поместите все свои комментарии в одну таблицу comments, но которая ссылается на мультимедиа из двух отдельных таблиц данных, вы не сможете легко установить ссылочную целостность между вашей таблицей комментариев и двумя таблицами данных. Есть некоторые обходные пути (например, наличие двух отдельных полей ссылок, по одному для каждого), но ни один из них не является действительно убедительным. Отсутствие ссылочной целостности в конечном итоге приведет к «зомби-данным», которые не принадлежат ни к одной из существующих медиа-записей.

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

По этой причине, если у вас есть две отдельные таблицы данных, я всегда предпочитаю использовать две отдельные таблицы комментариев.

Это немного больше зависит от того, как структурированы фотографии и видео. Рассмотрим следующий дизайн БД:

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, а не к одной из них, а не непосредственно к таблице Photos или Videos. Я часто использую этот тип дизайна, когда фото и видео имеют много общих свойств. Это особенно полезно, когда вы хотите делать такие вещи, как безопасность, потому что вы не вынуждены повторять одни и те же конструкции видимости и владения для каждого типа носителя, с которым вы имеете дело. Кроме того, запросы выполняются довольно быстро, поскольку многие запросы часто ищут только общие свойства или только строки, относящиеся к определенному типу, поэтому некоторые таблицы не нужно включать. Проектирование базы данных путем моделирования этих отношений IS-A также обеспечивает высокую избирательность ваших индексов, что означает скорость.

Если вы привязаны к своему дизайну, а видео и фото не имеют общей «базовой таблицы», то я бы сделал для каждого отдельную таблицу комментариев.

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

Я не думаю, что выбор между 1 или 2 таблицами для комментариев окажет заметное влияние на производительность вашего приложения.

Вы должны выбрать тот, который имеет больше смысла в контексте вашего приложения.

Например, если комментарии к фотографиям и комментарии к видео будут действовать одинаково, у вас должна быть одна таблица, если, однако (например), комментарии к видео могут быть в два раза длиннее, чем комментарии к фотографиям, или комментарии на фотографиях есть дополнительное поле «рейтинг» или что-то в этом роде, тогда 2 таблицы будут иметь больше смысла.

ваши запросы будут выглядеть как

select * from comments where linked_id = 555

or

select * from comments where linked_id = 555 and comment_type = 1

(с типом комментария = 1, что означает, что это видео).

Пока тип комментария является индексом, они в основном будут такими же быстрыми.

Единственное, что я бы рассмотрел, это столбцы. Если в комментариях к видео набор комментариев отличается от комментариев к изображениям, разделите их. Если все одинаково, держите их вместе.