Имея столбец number_of_likes или отдельный столбец ...?

Question

В моем проекте мне нужно * вычислить 'number_of_likes' для конкретного комментария *.

В настоящее время у меня есть следующая структура моей таблицы comment_tbl :

id    user_id   comment_details
1     10        Test1
2     5         Test2
3     7         Test3
4     8         Test4
5     3         Test5

И у меня есть еще одна таблица 'comment_likes_tbl' со следующей структурой:

 id    comment_id   user_id
  1       1         1
  2       2         5
  3       2         7
  4       1         3
  5       3         5

Выше приведены примеры данных.

Вопрос:

На моем живом сервере около 50 тыс. Записей.И я вычисляю * number_of_likes для конкретного комментария путем объединения двух вышеуказанных таблиц *.И мне нужно знать, все ли в порядке?

Или у меня должно быть еще одно поле к таблице comment_tbl , чтобы записать число_подключений и увеличивать его на 1 каждый раз, когда оно нравится, и вставлять его в comment_likes_tbl ....?

Помогло ли это мне в любом случае ...?

Заранее спасибо .....

Answer 1

Да, у вас должно быть еще одно поле number_of_likes в таблице comment_tbl. Это уменьшит ненужное объединение таблиц.

Таким образом, вам не нужно присоединяться, пока вам не нужно узнать, кому понравился комментарий.

Хороший пример, который вы можете увидеть здесь, - это проект базы данных самого StackOverflow. См. таблицу Users, у них есть поле Reputation с самой таблицей Users. Вместо того, чтобы присоединяться и вычислять репутацию пользователя каждый раз, когда он использует это.

Answer 2

Вы можете использовать несколько разных подходов к чему-то подобному

1. . В данный момент вы выполняете запрос JOIN, чтобы получить результаты сопоставления комментариев и количество «лайков» каждого.имеет
2. Со временем, вы можете обнаружить, что это снижение производительности.Вместо этого вы могли бы просто иметь счетчик, который увеличивается с каждым полем комментария.Но может оказаться полезным также сохранить вашу таблицу * comment_likes_tbl *, так как это будет постоянная запись того, кому что понравилось и когда (в противном случае у вас была бы просто одна фигура без дополнительных метаданных)
3. Возможно, у вас также может быть решение, в котором вы просто сохраняете лайки своего пользователя в comment_likes_tbl, и тогда задача cron будет запускаться по заранее заданному расписанию для автоматического обновления всех «лайков» по ​​всем направлениям.В дальнейшем, с более загруженным сайтом, это может потенциально помочь выровнять производительность, даже если это означает, что «подобные» отсчеты немного отстают от реального подсчета.

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

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

Answer 3

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

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

Даже если у вас возникнут проблемы с производительностью, вы должны сначала ...

• проверить, используете ли вы (иностранный)ключи, чтобы MySQL мог очень быстро искать данные
• воспользоваться кешем MySQL Query
• использовать своего рода 2-й уровень кэширования, например memcached для хранения значения лайков (так как это толькоинкрементное значение).

Использование memcache решит вашу проблему с запуском слишком большого числа соединений и позволит избежать создания ненужного столбца.

Answer 4

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