База данных: несколько таблиц или только одна таблица? - PullRequest
4 голосов
/ 11 июля 2010

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

  1. Чтобы иметь 2 таблицы для комментариев: photo_comments и video_comments

  2. Или иметь 1 таблицу comments и создать строку внутри таблицы как type и поместитьесли это photo_comment или video_comment

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

Пожалуйста, дайте мне знать, как лучше, скорость очень важна для меня.

Я говорю об очень большой системе с миллионами данных, миллионамикомментариев, поэтому я хочу самый быстрый способ получить результаты, для меня не имеет значения, нужно ли мне больше кодировать или нужно помнить что-то в плюсе, результаты гораздо важнее!

Ответы [ 6 ]

7 голосов
/ 11 июля 2010

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

Почему?

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

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

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

4 голосов
/ 11 июля 2010

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

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 .

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

0 голосов
/ 11 июля 2010

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

select * from comments where linked_id = 555

или

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

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

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

0 голосов
/ 11 июля 2010

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

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

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

0 голосов
/ 11 июля 2010

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

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

0 голосов
/ 11 июля 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...