Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Программирование. Ступени успешной карьеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум (новые сообщения вниз) Структурный форум

тема: Система обмена сообщениями

Сообщения:  [1-6] 

 
 автор: Trianon   (29.08.2006 в 18:59)   письмо автору
 
   для: Skyonex_   (29.08.2006 в 18:16)
 

От количества - нет. А от того, что запись переменной длины - очень даже зависит.

   
 
 автор: Skyonex_   (29.08.2006 в 18:23)   письмо автору
 
   для: RV   (29.08.2006 в 04:44)
 

Пример того, что мне нужно, можно посмотреть на любом сайте знакомств. Интересует система обработки и хранения на таких сайтах сообщений пользователей.

   
 
 автор: Skyonex_   (29.08.2006 в 18:16)   письмо автору
 
   для: Trianon   (29.08.2006 в 09:15)
 

А как максимум? И как это облегчит жизнь базы? Я как-то задавал вопрос на этом же форуме, зависит ли скорость обработки от кол-ва полей в таблице. Меня уверили, что нет.

   
 
 автор: Trianon   (29.08.2006 в 09:15)   письмо автору
 
   для: Skyonex_   (29.08.2006 в 02:56)
 

Я бы как минимум отпочковал поле переменной длины (message) в отдельную таблицу. С тем же id.

   
 
 автор: RV   (29.08.2006 в 04:44)   письмо автору
 
   для: Skyonex_   (29.08.2006 в 02:56)
 

icq предполагает установку чего та на комп пользователя. например клиента.
у вас так же?
если нет то почему это не просто чат?

   
 
 автор: Skyonex_   (29.08.2006 в 02:56)   письмо автору
 
 

Посоветуйте пожалуйста.

Требуется создать систему, грубо говоря а ля ICQ с сохранением истории отправленных/ принятых сообщений. С помощью mysql и/или текстовиков. Главное требование - скорость обработки.

В данный момент имеем:

Таблица messages:

id int(11)
from_id int(11) //id отправителя
to_id int(11) //id получателя
message varchar(255) // само сообщение
postdate datetime //дата отправки
readflag bool //флаг о прочтении

И два индекса, один по полю from_id другой по to_id. Выборка для вывода сообщений имеет вид:


$query="select from_id,message,postdate,readflag from messages where (from_id=$fromid and to_id=$this->userid) or (to_id=$fromid and from_id=$this->userid) order by id DESC LIMIT $start,$perpage";


Данная таблица позволяет легко подсчитать кол-во новых сообщений (непрочитанных), а так же получить ID отправителей.

На текущий момент таблица уже насчитывает 1 300 000 полей при суммарном кол-ве пользователей в 15000. И как мне кажется, в будущем возросший объем может создать серьезные проблемы. Может я и ошибаюсь.

Но в любом случае хотелось бы как-то помудрее все это организовать или получить успокоение типа: "Оставляй как есть" (что вряд ли) :-)

Как вариант рассматриваю хранение истории сообщений в текстовиках (один txt на двоих собеседников), а в базе держать только данные о непрочитанных (От и Кол-во).

ps Как то уже задавал здесь примерно такой же вопрос, но ничего интересного в ответ так и не получил.

   

Сообщения:  [1-6] 

Форум разработан IT-студией SoftTime
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования