Клиент -> сервер -> бд?

[djfile]

Здравствуйте. Объясните пожалуйста, правильно ли я понимаю принцип работы клиент-серверного приложения и помогите кое-какие пробелы заполнить?
Есть клиент, он хочет сделать запрос к серверу (как его делать в виде какого-то самописного протокола или в самом клиенте формировать SQL-запросы и передавать их серверу?), сервер получает запрос, обрабатывает его, делает выборку в бд и так далее. Результат запроса отдаем обратно клиенту (в каком виде? XML?).
Это вариант работы на выборку, а как реализовать вариант на добавление/изменение записей? Всё ещё сложнее...

[Bepec]

Всё очень просто. Клиент - серверное приложение. Найдёте тут упоминание БД - кричите, я прибегу

Клиент отправляет запрос на сервер. Сервер получает, обрабатывает, посылает ответ. Всё.

Остальное лишь подробности реализации

[djfile]

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

[Bepec]

В каком вам угодно. Посмотрите, погуглите, почитайте. Если нужна безопасность - один, если не нужна - другой. Если бесплатно - третий, если платно - четвёртый, если сам - то самому писать протокол.

Самое простое - пока клиент не залогинен, сервер от него пакеты в базу не принимает.

Вообще - почитайте о клиент-серверных приложениях и базах данных. Книг полно.

[djfile]

Ответьте на следующие вопросы и тему можно закрыть.
1) Клиент общается с сервером, по принципу: отправили пакет, в котором стоит какая-то команда (число), получили соответствующий ей ответ?
2) В каком формате передаются данные от клиента к серверу?

[V1KT0P]

Ответьте на следующие вопросы и тему можно закрыть.
1) Клиент общается с сервером, по принципу: отправили пакет, в котором стоит какая-то команда (число), получили соответствующий ей ответ?
2) В каком формате передаются данные от клиента к серверу?

1) Не обязательно, ты сам решаешь на какие команды нужны ответы на какие не нужны.
2) Да как захочешь, можешь текстом, можешь в бинарном виде, можешь в XML/JSON. А можешь вообще комбинировать.

[djfile]

Ответьте на следующие вопросы и тему можно закрыть.
1) Клиент общается с сервером, по принципу: отправили пакет, в котором стоит какая-то команда (число), получили соответствующий ей ответ?
2) В каком формате передаются данные от клиента к серверу?

1) Не обязательно, ты сам решаешь на какие команды нужны ответы на какие не нужны.
2) Да как захочешь, можешь текстом, можешь в бинарном виде, можешь в XML/JSON. А можешь вообще комбинировать.

Запросы к БД может выполнять только мой сервер?

[V1KT0P]

БД может выполнять только мой сервер?

Как ты захочешь так и будет, можешь открыть доступ к БД наружу без авторизации, можешь с авторизацией, можешь закрыть и дать возможность получать информацию через свой сервер(самое лучшее решение).

[djfile]

БД может выполнять только мой сервер?

Как ты захочешь так и будет, можешь открыть доступ к БД наружу без авторизации, можешь с авторизацией, можешь закрыть и дать возможность получать информацию через свой сервер(самое лучшее решение).

Вот так понятнее=)
Короче, это я копаю тему для курсовой. Тема курсовой: учет тех осмотра ТС. Понятно, что данные должны быть закрыты от посторонних. Вот я и думаю как лучше это всё сделать. Раньше на Qt только интерфейсы делал, а тут решил 2х зайцев убить: и курсач и работу с сетью изучить.

[joker]

А можно, можно я влезу?

На практике используют 2 вида клиент-серверных архитектур : двузвенная и трехзвеннная.

Двузвенная выглядит так: сервером выступает сама БД. Клиент цепляется к БД и выполняет необходимые запросы.

В трехзвенной же есть промежуточный сервер:  клиент общается с промежуточным сервером, сервер общается с БД.

Плюсы и минусы есть у каждого способа:

двузвенка на порядок проще и гораздо менее требовательна к ресурсам. Однако вся логика переносится на клиента = более высокие требования к оборудованию.

трехзвенка позволяет унифицировать обработку при разных клиентах (Rich-клиента, тонкий веб клиент, Android и iOS клиенты), позволит иметь возможность смены СУБД (клиент то запрос отправляет серверу), облегчит масштабирование системы (опять же потому что клиенту все равно что там будет твориться).
Однако такую систему сложнее разрабатывать и поддерживать.

В результате, ИМХО конечно же, Вам все же было бы проще работать с двузвенкой, а не трехзвенкой (которую вы и обсуждаете).

 

[djfile]

А можно, можно я влезу?

Конечно влезайте.

На практике используют 2 вида клиент-серверных архитектур : двузвенная и трехзвеннная.

Двузвенназя выглядит так: сервером выступает сама БД. Клиент цепляется к БД и выполняет необходимые запросы.

В трехзвенной же есть промежуточный сервер:  клиент общается с промежуточным сервером, сервер общается с БД.

Плюсы и минусы есть у каждого способа:

двузвенка на порядок проще и гораздо менее требовательна к ресурсам. Однако вся логика переносится на клиента = более высокие требования к оборудованию.

трехзвенка позволяет унифицировать обработку при разных клиентах (Rich-клиента, тонкий веб клиент, Android и iOS клиенты), позволит иметь возможность смены СУБД (клиент то запрос отправляет серверу), облегчит масштабирование системы (опять же потому что клиенту все равно что там будет твориться).
Однако такую систему сложнее разрабатывать и поддерживать.

В результате, ИМХО конечно же, Вам все же было бы проще работать с двузвенкой, а не трехзвенкой (которую вы и обсуждаете).

 

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

[joker]

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

Абсолютно верно.

Кста, могу еще обратить внимание, что в обоих случаях нагрузка на SQL сервер фактически одинаковая  
(да можно начать рассуждать о том, что в некоторых случаях app-сервер может кешировать, а с другой стороны унификация запросов приведет к более тяжелым запросам но это все будут уже особенности реализации)

[djfile]

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

Абсолютно верно.

Кста, могу еще обратить внимание, что в обоих случаях нагрузка на SQL сервер фактически одинаковая  
(да можно начать рассуждать о том, что в некоторых случаях app-сервер может кешировать, а с другой стороны унификация запросов приведет к более тяжелым запросам но это все будут уже особенности реализации)

Спасибо большое за помощь. Теперь бы выбрать как лучше сделать для курсовой=) Прочел, что с QSqlDataBase нельзя работать в нескольких потоках. Точнее QSqlQuery не может делать запросы из базы, находящейся в другом потоке.
И ещё как лучше держать связь с клиентами? Постоянно держать открытым сокет?

[joker]

Спасибо большое за помощь. Теперь бы выбрать как лучше сделать для курсовой=) Прочел, что с QSqlDataBase нельзя работать в нескольких потоках. Точнее QSqlQuery не может делать запросы из базы, находящейся в другом потоке.
И ещё как лучше держать связь с клиентами? Постоянно держать открытым сокет?

Ну пункт номер раз - а зачем тебе несколько потоков?
В стандатном варианте:
 - или нужно показывать виджет - таблицу / форму - тут все стандартно без потоков.
 - или нужно делать апдейты/инсерты - но они обычно много времени не занимают (иначе надо перепроектировать приложение).
 - или нужно считать отчеты... но ползателю все равно их ждать - раз ему нужны отчеты - поэтому проще вывести какое нибудь окошко статуса чтобы скрасить ожидание.

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

[k0p4]

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

1. QSqlDatabase можно вынести в отдельный трэд. В каждом трэде можно открыть коннекшн. Соотвтветственно, работа для БД будет приезжать с сигналом, и результат выполнения - тоже будет уезжать с сигналом.
2. Помимо основной таблицы БД тебе нужен стол пользователей, где будут хранится, например, логин-пасс.
3. Коннекшн с твоим сервером должен висеть только ПОСЛЕ аутентификации. Время на прохождение аутентификации должно быть маленьким. Так же не забудь про таймауты. Т.е. если соккет, к примеру, минуту тебе ничего не шлёт - ты его отрубаешь. Что бы не отрубать нормальные соккеты, который сейчас просто не активны, каждые 55 секунд шлёшь какую-нибудь команду и рестартуешь таймер.