клиент сервер через mysql

[Stilet]

через какой период времени надо обновлять?

Ты выкладываешь обновки. Юзер при подключении к БД проверяет есть ли чего "покушать в холодильнике", и если есть - твоя клиентская система должна уметь самообновляться (желательно с сохранением откатов, дабы при неудачной обновке вернуться на прежнюю рабочую версию)

потому что если юзер будет чтонить вбивать, а потом у него обновиться и все собъется

Автоматом обновлять ни в коем случае. Обязательно предложением юзеру, и пусть он сам решает.

[eval]

пишу для работы, сервак отдельный с mysql есть, делфи без проблем соединяется по внешнему ip.

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

[Vladiger]

Автоматом обновлять ни в коем случае. Обязательно предложением юзеру, и пусть он сам решает.

Я думаю он имел ввиду не глобальные обновления которые необходимо извлечь с БД или с сервера и установить, а немного другое:
- Предположим в сети два юзверя, общаются в чате, оба получают данные из БД MySQL. Один написал "Здарова чувак!", база данных обновилась, но второй юзверь об этом не знает. Предлагать ему обновляться после каждой мессаги, ну как то тупо будет, особенно если в чате 50 юзверей...

Тут нужна какая то своя система итераций, либо читать из БД через определенный интервал только информация которой возможны изменения по функционалу программы, либо иметь на сервере (или в той же БД) какой то флаг, ответ в виде: - Опачки, а база данных то обновилась и в ней есть новые записи, бегом читать новые мессаги.

[undead92]

Сообщение от Vladiger

Я думаю он имел ввиду не глобальные обновления которые необходимо извлечь с БД или с сервера и установить, а немного другое:
- Предположим в сети два юзверя, общаются в чате, оба получают данные из БД MySQL. Один написал "Здарова чувак!", база данных обновилась, но второй юзверь об этом не знает. Предлагать ему обновляться после каждой мессаги, ну как то тупо будет, особенно если в чате 50 юзверей...

Тут нужна какая то своя система итераций, либо читать из БД через определенный интервал только информация которой возможны изменения по функционалу программы, либо иметь на сервере (или в той же БД) какой то флаг, ответ в виде: - Опачки, а база данных то обновилась и в ней есть новые записи, бегом читать новые мессаги.

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

[Vladiger]

Вообще для таких приложений, где идут диалоги между одним сервером MySQL и толпой клиентов, ИМХО нужно писать свой сервер который и будет вести эти диалоги. Но это не MySQL сервер, это как раз промежуточное звено для связи "общественности с президентом".
На мой взгляд не очень хорошая ситуация, когда к одному серверу MySQL одновременно подключены сотни клиентов. Неизвестно чего они могут там нагородить и хуже всего то что сами между собой запутаются. Каково например предположить ситуацию (почти не реальную) когда два или три юзверя, попытаются сделать запись в БД практически в один момент времемени?

Примером такого сервера может служить PHP, это для Web. То есть PHP сервер сам (один) подключается к БД и сам делает там все изменения, а всех клиентов об этом даже не уведомляет, потому что в Web в этом нет необходимости. Клиенты получают обновленную инфу по мере обновления страниц.

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

Кладовщик на овощной базе - это и есть сервер самой овощной базы, думаю так понятней. Клиент просто приходит и говорит: - Дайте мне помидор. А Кладовщик отвечает: - Помидоры закончились, обратитесь завтра...

Так вот видимо вам и нужно писать сервер "кладовщик".

PS Но опять таки это мое ИМХО, я бы поступил именно так.

[undead92]

Сообщение от Vladiger

Вообще для таких приложений, где идут диалоги между одним сервером MySQL и толпой клиентов, ИМХО нужно писать свой сервер который и будет вести эти диалоги. Но это не MySQL сервер, это как раз промежуточное звено для связи "общественности с президентом".
На мой взгляд не очень хорошая ситуация, когда к одному серверу MySQL одновременно подключены сотни клиентов. Неизвестно чего они могут там нагородить и хуже всего то что сами между собой запутаются. Каково например предположить ситуацию (почти не реальную) когда два или три юзверя, попытаются сделать запись в БД практически в один момент времемени?

Примером такого сервера может служить PHP, это для Web. То есть PHP сервер сам (один) подключается к БД и сам делает там все изменения, а всех клиентов об этом даже не уведомляет, потому что в Web в этом нет необходимости. Клиенты получают обновленную инфу по мере обновления страниц.

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

Кладовщик на овощной базе - это и есть сервер самой овощной базы, думаю так понятней. Клиент просто приходит и говорит: - Дайте мне помидор. А Кладовщик отвечает: - Помидоры закончились, обратитесь завтра...

Так вот видимо вам и нужно писать сервер "кладовщик".

PS Но опять таки это мое ИМХО, я бы поступил именно так.

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

А насчет сервера- посредника клиента и базы это впринципе и был вопрос изначально, хотелось бы какие-нибудь примеры,не совсем понятно что именно делает сервер

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

[eval]

Кладовщик на овощной базе - это и есть сервер самой овощной базы, думаю так понятней.

сие есть бред, вы бы почитали сначало чего, а то больно слушать вашу теорию

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

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

[Vladiger]

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

Так то оно так, всё верно. Казалось бы: - Нафига промежуточное звено, если можно без посредников, ворваться на овощную базу и убедиться что помидоры и вправду закончились?

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

А вот если бы было промежуточное звено, то ситуация с обращениями в БД могла бы выглядеть примерно так:

Клиент серверу: - HELO
Сервер устанавливает соединение, выделяет канал и ресурсы новому клиенту, отвечает: - OK

Клиент серверу: - GET MESSAGES
На основании того, что клиент только что подключился, делает запрос в БД и посылает клиенту сообщения из БД, при этом ждет от клиента уведомление о получении.

Клиент серверу: MESSAGE RECEIVED OK
Сервер уведомлен что данный клиент получил все сообщения и у себя в памяти устанавливает этому клиенту булевый флаг TRUE (сообщения доставленны)

Далее начинаются непрерывные итерации клиент <-> сервер до тех пор пока кто нибудь не напишет новое сообщение и сервер не пометит у себя что в БД появились обновления:

Клиент серверу: GET MESSAGES
Сервер клиенту: EMPTY
Клиент серверу: GET MESSAGES
Сервер клиенту: EMPTY
Клиент серверу: GET MESSAGES
Сервер клиенту: EMPTY
Клиент серверу: GET MESSAGES
Сервер клиенту: EMPTY

Клиент и сервер могут гонять туда сюда 1 байт сколько угодно, при этом в БД не будет сделано ни одного запроса. Время итераций тоже может быть какое угодно, например 50-100 мс.

Но в какой то момент один из клиентов отправит новую запись:
Клиент серверу: SEND "Бла-бла-бла-бла"
Сервер добавит запись в БД и сбросит флаги о доставке сообщений всем подключенным клиентам в false и ответит: OK

При следующем цикле первого клиента GET MESSAGES, сервер уже ответит не EMPTY, а отправит новые сообщения, после чего опять подождет уведомление о получении и опять отметит что сообщения доставлены... И так далее...


То есть получается какая то совсем не нужная возня. Спрашивается: - А нафига это всё, какие то заморочки с диалогами, ответами типа EMPTY?
Просто таким способом можно разгрузить БД, не напрягая её постоянными запросами. Представь 20 юзверей с тем же интервалом в 50-100 мс. непрерывно долбят и долбят эту БД, пока она не сдохнет. А ведь она может быть совсем не маленькой и на обработку таблиц сервер может затрачивать нехилые ресурсы.

Сообщение от eval

а то больно слушать вашу теорию

Кеторол, Темпалгин - хорошие обезбаливающие!

[undead92]

спасибо, попробую