Форум PHP

Ну не знаю, я лично не представляю корпаративное решение на гольном веб. База клиентская содержит приватные данные, и сеть используется для обмена данными между офисами. А вот для клиентов выставляется только часть из этих данных, публичная, и через, например, личный кабинет, частная, на сервере. Изменение данных в клиентской базе отражаются в базе на сервере.

PS. У вас ведь в любом случае будет головной офис, он и должен содержать клиентскую базу данных, а значит и обновление серверной базы, это задача одного офиса.

Ясно.Спасибо, буду думать.


p.s. Честно говоря мне не очень нравится оконные приложения. Технологи используют у себя только линукс, поэтому если придется делать как говорите вы, то придется использовать кроссплатформеные решения. По времени затрано. Ну это уже другой вопрос

Это - само собой.

Хотя на мой взгляд, здесь лучше применить генерируемый в момент создания кода формы жетон, код которого записывать в скрытый параметр формы и в БД - на место предполагаемой записи.
И запись менять по этому жетону, фиксируя последнюю версию контента.

это достаточно скользкая дорожка :)
пилите перенаправляйте, Шура, перенаправляйте... :)

Офис А обрабатывает жалобы Пупкина, Иванова, Николаева....
Офис Б обрабатывает жалобы Сидорова, Петрова....
Технолог офиса А отправляет на сервер С уже готовые решения по этим жалобам, с подтверждением получения....
Технолог офиса Б отправляет на сервер С уже готовые решения по этим жалобам, с подтверждением получения....
Сервер С получает эти данные и, или добавляет их, или обновляет, все зависит от того, как орагнизована база данных.

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

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

Что значит обновлять?

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

Я имел ввиду это

>Согласен. Но усилия должны быть оправданы. А решение должно быть продуманным. Валик предложил хорошее решение. Я примерно так и поступил.

Так и в Valick'овом решении header|location никуда не исчез :) как я вижу.

Ну даже в этом случае, не будет же оператор-приемщик из одного офиса, давать задание оператору-технологу из дугого офиса. А база общая (для клиентов), так кто мешает ее обновлять данными из разных офисов?

Использую тонкий клиент. Есть вероятность, что на другом конце города откроется еще один офис. фирма у нас маленькая, растет по-тихоньку.