простой выбор/выбор нескольких пользователей

Question

Я вижу множество реализаций, таких как Facebook, форум karma, отметка как прочитанная на сообщениях форума и другие простые варианты и варианты, доступные для нескольких пользователей по данному элементу.

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

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

Есть ли другой способ реализовать эти системы, если нет, есть ли оптимизации, такие как типы баз данных или другие настройки, которые могут сделать это быстрее?

В принципе, существует мощная, быстрая реализация взаимодействия многих и многих баз данных.

* EDIT *** Я использую оперу мини и поэтому у меня есть проблемы с AJAX и JS для комментирования

---

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

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

Мой сайт позволяет многим пользователям размещать свои собственные сайты, и поэтому мне нужно серьезно их оптимизировать.

Кто-то предложил использовать для этого таблицы памяти.

---

Примечание * * я не могу использовать Memcached.

Answer 1

Я настоятельно рекомендую использовать что-то другое, чем БД MySQL. Я написал открытое приложение, которое было как тяжелым, так и записываемым в базу данных. Все началось с БД MySQL, я даже переключился на специальную настройку репликации подчиненных мастеров. Но безрезультатно, это было дорого и не очень хорошо масштабировалось.

Окончательным решением было использование NoSQL db, которое максимально использовало ОЗУ. Мое решение состояло из mongoDB, у которого было сообщество активистов, и я очень хорошо решил свою проблему. MongoDB доказал свою высокую масштабируемость.

Answer 2

Еще немного туманно о том, что вы получили до сих пор, но я начну его и продолжайте добавлять материал, в случае необходимости:

1. Убедитесь, что вы Индексация
2. Минимальные поиски -SO вас получить список должностей, которые будут всплывал, использовать этот список, чтобы соответствовать как-х, если они рассматривали статью и т.д.
3. Использование номера - убедитесь, что все ваши сравнения с номерами
4. Если вы» re running que ries, не запускать ни одного запроса для каждого сообщения
5. Есть ли предел в вашем запросе? - убедитесь, что вы используете это
6. Де-нормализация не является грехом
7. Вы можете разбить базы данных для уменьшения поиска (например, если данные старше 60 дней и едва затронуты, переместите их во вторичную базу данных/таблицу, поэтому размер вашего стола не огромен)

egSELECT * FROM user_liked WHERE post_id IN (1,2,3) вместо

SELECT * FROM user_liked WHERE post_id = 1 

Answer 3

Филипп Келлер написал несколько статей о системах тегов на базе MYSQL. Точно так же, как «Пометить», Tagging устанавливает отношения «многие ко многим» между вещью (тегом, статьей, которая нравится) и пользователем. Логика в его статьях должна быть непосредственно применима и к вашей проблеме.

Ознакомьтесь также с комментариями.

• http://www.pui.ch/phred/archives/2005/04/tags-database-schemas.html База данных Schemas решений Tagging
• http://www.pui.ch/phred/archives/2005/05/tags-with-mysql-fulltext.html злоупотребляя индексы FULLTEXT MySQL для мечения и поиска тегов (требуется MyISAM, я не пошел бы туда).
• http://www.pui.ch/phred/archives/2005/06/tagsystems-performance-tests.html Производительность Испытания систем мечения