Хочу написать.. Не знаю с чего начать..

Давно горел желанием написать чат.
Но незнаю с чего бы начать все это)))

Предложите структуру движка для этого?? а я попробую....

Добавление сообщений.
форма ввода сообщения -> AJAX передаёт время передачи сообщения, само сообщение и автора сообщения обработчику сообщений -> обработчик записывает их в БД
Показ сообщений.
AJAX каждые 30 секунд вызывает JSON-данные с сервера -> сервер выдаёт что-то вроде этого

-----
Не помогли на форуме? Не растраивайтесь!

Stierus
1) база данных пользователей (привелегии, личные данные, разл. служебная информациЯ типа ип и тому подобное);
2)система авторизации
3)система отправки сообщений и система анализа (типа антимата и обращения к конкретным участникам)
4)система вывода сообщений из базы или файла с предварительным форматированием текста согласно личным настройкам пользователя;
5)система администрирования всего этого
5)система дополнительных сервисов для пользователей
6)может еще чего-нибудь что я пропустил;
Мне нужна структуроа "как это все воедино связать"..

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

Если у тебя ICQ есть напиши мне сейчас.

-----
Не помогли на форуме? Не растраивайтесь!

Carzil
есть но сейчас не могу написать...
могу номер дать а в сети буду только дня через 4
408669845

Я с тобой согласен. Я на планирование своей соц сети потратил уже три месяца и ещё до сих пор работаю.

-----
Не помогли на форуме? Не растраивайтесь!

Удалил

ok.
уже умчал лепить новый хост и БД. с нее и начну. За советом еще приду.
советуйте кто чего сможет....

Carzil, через час буду в асе, номер есть, стучи)))

Я через час не могу. Давай завтра.

-----
Не помогли на форуме? Не растраивайтесь!

первый вопрос по поводу этой самой базы:
какое количество запросов к базе не считается вредным? (рассматривается естественно динамическая страница)

Каждый запрос и функция по определению снижают скорость отдачи страниц. Так что стремиться надо всегда к 0.
"не считается вредным" - не совсем корректный вопрос, не вредным будет чем меньше, тем лучше для одного и того же эффекта.

-----
PostgreSQL DBA

Самый простой способ:

Создать файл chat.txt
PHP скриптом считать его, и вывести.
Использовать форму ввода сообщений.

Каждое новое сообщение дописывать в файл примерно так:

<b>$userName</b> <i>$date</i> $message <br>

Ну, и, создать некий chatAnswer.php который вызывать при добавлении ответа.

AJAX использовать желательно, но не обязательно.
Достаточно поставить JS таймер на обновление содержимого.

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

Мелкий
база данных какая то большая получилась у меня)))
мне удобнее использовать несколько таблиц, так как разная информация используется разными скриптами. всего около 50 полей для каждой записи. обращение к конкретной таблице происходит в определенном случае. зависит ли от количества таблиц что то еще кроме удобности использования(для меня лично) ??
(Добавление)
как вариант уменьшения количества запросов к базе данных:
можно ли "построить" профиль один раз при загрузке страницы и возложить его (профиля) хранение на плечи JS дабы не обращаться многократно за какими то характеристиками юзера. То биш - при построении главной страницы обращаемся к базе данных, читаем все необходимиые характеристики и записываем профиль в JS (может объект создать или еще как нибудь) и далее при отправке сообщения все "параметры" юзера необходимые для его обработки и форматирования JS добавит сам к сообщению а скрипт обработки их уже использует по назначению....
можно так или не стоит?????

JS работает на стороне клиента. Следовательно пользователь сможет сам выставлять эти параметры, например, для того, чтобы отправлять сообщения от чужого имени...

Объём базы и количество запросов, собственно, никак не связаны.
Наибольшую задержку даёт подключение к СУБД, пересылка запросов-ответов, разбор запроса на стороне СУБД. Непосредственно выборка данных происходит очень быстро.

Скорость выполнения запроса зависит от количества задействованных в запросе таблиц, а в остальном - таблицы в базе данных никак физически не связаны (только логически, что и надо реализовывать в запросах) и друг на друга потому не влияют.
Вообще, по теории реляционных баз данных - все таблицы с повторяющимися данными (в пределах одного поля, в частности) надо делить на несколько таблиц, т.е. большое количество таблиц приветствуется. Но выборка и предшествующее ей связывание таблиц работает тем медленнее, чем больше участвует таблиц. Так что оптимум где-то посередине...


А что у юзера за характеристики в чате? К которым надо многократно обращаться?


Пользователь так или иначе сможет это сделать в любом случае, т.к. со 100% уверенностью сказать, что сейчас к серверу обратился тот же человек, что и 5 секунд назад - невозможно.

(Отредактировано автором: 16 Декабря, 2009 - 11:20:06)

-----
PostgreSQL DBA