Привет! Как организовать правильно: Типа как на youtube, like, dislike. Вопрос только в одном, где хранить информацию о том что уже поставлен голос, именно что конкретный пользователь поставил, и ему больше нельзя ставить, только отменить.
1000 фотографий, 1000 пользователей, это у же внушительная цифра. Пока что вижу два варианта: для каждого пользователя создавать файл, и вносить инфу к какаим фотках ставил лайки. Второй способ - все это в сессию, когда сессия закрывается данные в базу, новой авторизации извлекать из базы сессию и присоединять к пользователю. По моему это гиморно
Интересно почему тебе не пришло в голову засунуть в сессию всё остальное, что будет на сайте. Ведь его тоже дофига и оно тоже выводится 100500 раз. Почему именно лайки внезапно потребовали оптимизации? Добавлено спустя 4 минуты 11 секунд: Оптимизировать надо то, что реально создает критические нагрузки. Если тебя беспокоит справится ли база с 1млн записей — да запросто! Следи за тем, чтобы на отображение одной страницы у тебя не было 100 запросов к базе и всё будет хорошо.
Я не говорю про оптимизацию, я говорю про здравый смысл. А если не 1000 лайков. А 10000 лайков и 10000 фоток. Как то это по другому делается. А потом при выводе фотографии, поиск по базе получится не хилый.
точно И? ведь это ВСЕГО 10000 строк. базы и не такие огромные бывают. и кстати до вас этого никто не боялся а тут вдруг оказывается весь мир не прав и неоптимально работает с лайками.
ну и? это 100млн записей если квадрат. но вряд ли каждый пользователь будет лайкать каждую фотографию. так что меньше. ну допустим 100млн. по 4 байта на айдишник юзера, 4 байта на айдишник изображения, 1 байт на оценку. это примерно 9 байт на строку. ну будет таблица 900 мегабайт (не путать с мебибайтами). даже допустим я лох и считать не умею - пусть будет таблица два гигабайта. это вообще ни о чем для любого современного сервера субд. даже если индексы будут по юзеру, по фотке и третий по паре юзер-фотка - все равно субд это будет щелкать в легкую. во-во. вместо попытки нас убедить в том что теория у нас не та - уже давно можно было на локальной машине создать эталонную таблицу да запросами её засыпать - увидеть как долго идет добавление/обновление, сколько выборка занимает, подумать куда можно оптимизировать.
Нет, дружище, ты именно про оптимизацию говоришь. Поэтому давай смотреть что действительно важно. Еще раз скажу: главное не делать 100+ запросов на странице. Если ты предполагаешь при выводе ста фоток сто раз запросить базу "а нет ли там лайка от пользователя X?" это конечно проблема. но ты так не делай Грубо говоря накопи 100 айдишников и запроси их в одном запросе. Собственно из запрета на повторный лайк еще не следует, что ты при выводе страницы должен знать про лайк конкретного пользователя. Это знание понадобится при попытке лайнуть - тогда и проверишь. Инсерт и Апдейт бывают намного реже, чем Селект. Допустим чувак пытается лайкнуть, ты без проверки фигачь INSERT. Уникальный индекс должен помешать вставить лишнее. Если инсерт не прошел, значит лайк уж был, тогда делай DELETE - т.е. дизлайк. Опять же люди лайкают намного чаще, чем снимают лайки. Поэтому в большинстве случаев выполнится только одна команда на изменение. Я понятно объясняю?
А как такой вариант: В таблице с лайками создаем поле longtext, и фигачим туда массив с id проголосовавших чуваков.
тогда зачем реализация которая не дает примитивной функциональности? а как узнать лайкали ли фотку допустим три конкретных юзера? а если дату-время лайка нужно будет прикрутить? а если это оценки?
Подскажите, как сделать запрос, если нужно проверить на уникальность не одно поле, типа id, а скажем id фотографии и id пользователя? Если есть и id фотки и id пользователя, то удаляем лайк. Я имею в виду проверку с помощью sql
[оффтоп]Если кому интересно - вот яркий пример оверквотинга. Каноничный. Автор процитировал даже собственную цитату из чужого поста. Причем совершенно не ясно, на какую конкретно часть этого сообщения он отвечает.[/оффто]
В больших проектах для этих вещей используют Redis или другое хранилище типа ключ-значение. Это решает все проблемы. В конечное хранилище (не всегда это реляционные таблицы, но не суть, главное что на винты) периодически сбрасываются значения ключей. Однако, чтобы вам было понятно, тс, "большие" означает не 1000 пользователей и 1000 записей, а миллионы пользователей где тысячами измеряются количество создаваемых записей и лайков ежечасное. Поэтому объективно оцените нужно ли усложнять проект для решения задачи или достаточно простого асинхронного запроса на сервер с простым запросом мускулу а ля "Insert on duplicate key update...". Для этого сподручнее использовать составной ключ из двух полей и, например для мускула, конструкцию Insert on duplicate key update