помогите с логикой

← →
Faceless © (2012-01-06 14:26) [0]

Есть программа (клиент и сервер), работающая с БД. Нужно реализовать возможность экспорта / импорта данных из / в БД. Как поступать, если на момент экспорта / импорта с БД работает несколько пользователей. К примеру, один пользователь запустит операцию экспорта, в этот момент другими пользователями будет редактироваться БД. Что посоветуете? Может на момент экспорта / импорта блокировать работу с БД для все пользователей?

← →
артём (2012-01-06 14:31) [1]

а может чтоб она дублировалась на стороне клиента который делает экспорт а потом сливается обратно! или может стоит использовать буфер обмена... да что угодно можно использовать...

← →
артём (2012-01-06 14:33) [2]

и какая база данных используется в программе? db, dbf, mdb или oracle. Что используется?

← →
Омлет © (2012-01-06 14:34) [3]

Заворачивай всё в транзакции, субд сама заблокирует запить, где это необходимо.

← →
Омлет © (2012-01-06 14:35) [4]

> запить

запись

← →
Faceless © (2012-01-06 14:43) [5]

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

← →
DiamondShark © (2012-01-06 14:50) [6]

Для начала нужно сообщить тип СУБД.

← →
Anatoly Podgoretsky © (2012-01-06 14:52) [7]

> Faceless (06.01.2012 14:26:00) [0]

Используй нормальный клиент-сервер

← →
Faceless © (2012-01-06 15:00) [8]

> Для начала нужно сообщить тип СУБД.

СУБД: MS Access, программа писалась еще до меня.

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

Логика работы с программы такая:

К примеру, пользователь в программе-клиенте добавляет новый заказ. На этом этапе формируется XML с данными заказа и в виде текста отправляется через ClientSocket. Приложение-сервер принимает XML через ServerSocket, выполняет валидацию данных в XML и добавляет данные в БД. Таким образом весь код по работе с БД выполняется программой-сервером, приложения-клиенты только посылают socket-запросы с текстовыми данными в формате XML.

← →
stas © (2012-01-06 15:19) [9]

Faceless © (06.01.12 15:00) [8]

А зачем так?

может стоит прислушаться к
Anatoly Podgoretsky © (06.01.12 14:52) [7]

← →
Faceless © (2012-01-06 16:05) [10]

> А зачем так?

А чем плоха такая организация? Сделано так, чтобы при необходимости после какой-либо операции можно было разослать нужную информацию всем запущенным программам-клиентам.

← →
MsGuns © (2012-01-06 16:19) [11]

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

← →
stas © (2012-01-06 16:22) [12]

Faceless © (06.01.12 16:05) [10]
Клиент-серверная технология решено все на уровне сервера.
На клиенте указывается имя сервера и за всеми операциями следит сервер.

← →
Anatoly Podgoretsky © (2012-01-06 18:27) [13]

> СУБД: MS Access, программа писалась еще до меня.

Это не клиент-сервер. А файл-сервер

← →
sniknik © (2012-01-06 19:12) [14]

> Это не клиент-сервер. А файл-сервер
у него принцип клиент-сервер, т.к. есть программа клиент, и программа сервер. то что после сервер использует файл сервер, это уже не принципиально.
трехзвенка по другому. своя.

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

← →
Anatoly Podgoretsky © (2012-01-06 19:27) [15]

> sniknik (06.01.2012 19:12:14) [14]

Но он хочет не по принципам работать, а по своему и уверждает, что у него
клиент сервер. Только подлинный клиент сервер обеспечивает все прозрачно,
или по крайней мере выбрать нужный уровень изоляции транзакций. Данная СУБД
все таки это не обеспечивает.

кратко резюмирую всех вышевысказавшихся:
В текущей ситуации у тебя есть 2 пути:
1) Перевести данные в Клиент-серверную СУБД (Оракл, МССКЛ и т.п.)
2) Оставить всё как есть, добавив пул входящих запросов в программу-сервер - между валидацией и добавлением в БД. Там будут складироваться запросы на вермя обработки.
На время Экспорта/импорта(?!)/Резервной копии дожидаться окончание очередной операции с БД, стопать добавление из пула в БД, делать свое дело, и разрешать дальше работать.

вот как-то так.

> вот как-то так.

Вот молодец! Практически мою мысль озвучил! Я тоже хотел человеку предложить очередь создать. Хотя пункт №1 предпочтительнее и гораздо эффективнее.

← →
знайка (2012-01-13 14:43) [18]

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

> субд в инет выпускать никто не будет

эт почему же? кто запретит?

Да, насчет 1-го пункта - Тут СУБД сама будет разруливать блокировки, версии и прочую фигню, придуманную более головастыми чуваками, а ты будешь под них подстраиваться то тушкой, то чучелком :-)

Такая логика имеет полное право на жизнь, все зависит от задачи...
к [0]:
складывай xml-ки, но не обрабатывай их во время операций exp/imp и т.п.

помогите с логикой Найти похожие ветки