Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Есть сервер, с ним несколько раз в сутки устанавливается соединение и данные сливаются на другие компьютеры. Соответственно, во время следующих соединиений информацию с тех компьютеров надо запихать обратно на сервер. Установить постоянное соединение или приделать что-нибудь типа веб-сервисов нельзя - требование заказчика. Я могу писать лог для каждой отдельно взятой репликации и/или ставить признак изменения в строке типа LastModified и потом пытаться изменить базу на сервере соответственно логу/списку измененных строк. Но все равно остается проблема одновременного изменения одних и тех же данных разными юзерами. Фактически я вообще не вижу что тут можно придумать. Записывать последнее по времени изменение и уведомлять всех кто тоже менял эти данные? Не мог бы кто-нить посоветовать грамотное решение или хотя б дать ссылки на описание решений такого типа задач. Лучше с решением :) Спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 10:49 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
VicelЕсть сервер, с ним несколько раз в сутки устанавливается соединение и данные сливаются на другие компьютеры. Соответственно, во время следующих соединиений информацию с тех компьютеров надо запихать обратно на сервер. Установить постоянное соединение или приделать что-нибудь типа веб-сервисов нельзя - требование заказчика. Я могу писать лог для каждой отдельно взятой репликации и/или ставить признак изменения в строке типа LastModified и потом пытаться изменить базу на сервере соответственно логу/списку измененных строк. Но все равно остается проблема одновременного изменения одних и тех же данных разными юзерами. Фактически я вообще не вижу что тут можно придумать. Записывать последнее по времени изменение и уведомлять всех кто тоже менял эти данные? Не мог бы кто-нить посоветовать грамотное решение или хотя б дать ссылки на описание решений такого типа задач. Лучше с решением :) Спасибо При таком подходе к репликации сделать самостоятельно (т.е. без согласования с заказчиком) ничего нельзя. Слишком велик риск... Надо поставить вопрос (с вариантами решения) перед заказчиком: как он решит (чьи данные важнее (и их мы сохраним), а чьи нет (и мы их удалим)) так и будет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 10:58 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Вариант перехода, например, на MS SQL рассматривается? ___________________ Всё вышеизложенное есть моё частное мнение и не претендует на полноту изложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 14:18 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Воспользуйтесь поиском - тут мы довольно подробно обсуждали replication... и я описвал в частности свой последний проект из этой темы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.12.2004, 15:23 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
вариант с SQL Server'ом не рассматривается. Заказчик конкретно хочет фокспро. У него есть какой-то софт на vfp 3.0 и он хочет потом интегрировать все до кучи :) Я почитал форум, спасибо В итоге получам помечаем все измененные строки, заменяем ими строки в соответствующих таблицах на сервере (или оставляем то что было, в зависимости от того кто редактировал и от заказчика :) ). тогда вопрос такой Таблица имеет столбец ID (autoincrement). Если например в ней было 10 строк, мы сделали 2 копии с таблицы, а потом в каждую добавили по строке, одиннадцатой. На эти одиннадцатые строки есть ссылки в связанных таблицах. Потом мы сбрасываем строку из одной репликации на сервер (она становится 11-йв исходной талице) и ставим ссылки на нее. Теперь надо добавить строку из второй копии. Чтобы не оказалось что мы добавим ссылки на 11ю строку из первой репликации, я думаю надо изменить id этой строки в базовой таблице с 11 на 12. Ссылки изменятся соответственно тригером. Теперь мы добавляем 11ю строку из 2й репликации. И все ок. Выглядит вроде нормально. Я только не помню некоторых вещей - давно не работал с фоксом. В процессе надо изменить автоинкрементное поле. Как это сделать? можно сбросить флаг автоинкремента, изменить поле как надо и поставить инкремент обратно. Но в таком случае что будет с тригерами? и индексами? они не послетают? Что то я не уверен что получится. И вообще менять структуру базовой таблицы каждый раз... как-то мне не хочется может есть какой нибудь способ получше/понадежнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 13:02 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Я бы в этом случае не баловался бы с автоинкрементом... Надо меть несколько полей: - код филиала - уникальный ID для данного филиала - уникальный код (лучше всего код филиала+sys(2015)) далее у меня есть еще 4 поля - было добавлено - было удалено - информация обновлена на клиенте - информация была изменена на удаленном сервере далее определить правило для репликации - например самым высоким будет приоритет админа - он может менять все и его слово последнее, далее филиал имеет право менять свои данные, чужой филиал не имеет права менять чужие данные и т.д. Либо как альтернативу - взять не очень гибкую систему правил от SQL Server - таблица приоритетов клиентов - у кого больше, тот и прав во время конфликтов... В общем-то ничего сложного, правда писанины много... Good luck! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 13:40 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Hi Sergey! Только не надо опять SYS(2015) привлекать :( Уж если нужно нечто "этакое", то возьмите нормальный GUID. НО если есть стабильная система нумерации филиалов (т.е. код филиала ВСЕГДА определён для них всех) - то достаточно использовать его + ЛОКАЛЬНЫЙ (для филиала) автоинкрементный код - причём лучше НЕ AUTOINC, а нечто типа NewID(). Протокол (реализация) же репликации - вещь сложная, и зависит от многих "если". Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2004, 23:54 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Только не надо опять SYS(2015) привлекать :( Каждому свое Но когда этот большой номер от GUID вставляешь в каждую таблицу, то начинаешь невольно задаваться вопросом - а зачем я так много гоняю данных по сети ? Если у SYS(2015) вместо первых двух символов использовать алфавитно-цифровой код филиала и выдачу этго номера повесить на хранимую процедуру локального контейнера базы данных, то гарантируется уникальность в течении 200 лет... Я столько жить не собираюсь, а Вы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 00:14 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Sergey Ch Igor Korolyov Только не надо опять SYS(2015) привлекать :( Каждому свое Но когда этот большой номер от GUID вставляешь в каждую таблицу, то начинаешь невольно задаваться вопросом - а зачем я так много гоняю данных по сети ? Для начала, следует определиться, что для Вас важнее, объем данных или гарантированная уникальность этих самых данных Sergey ChЕсли у SYS(2015) вместо первых двух символов использовать алфавитно-цифровой код филиала и выдачу этго номера повесить на хранимую процедуру локального контейнера базы данных, то гарантируется уникальность в течении 200 лет... Откуда у Вас такая уверенность? Вы вскрыли код формирования SYS(2015)? Тогда поделитесь с общественностью. Может все тоже станут его использовать. Проблема с SYS(2015) вовсе не в первых символах, а как раз-таки в последних. Ведь SYS(2015) наращивает ASCII-код последних символов. При разных играх с системным временем и повышении быстродействия компьютеров, есть очень большая вероятность схлопотать повторяющееся значение. К сведению, из того, что процедура включена в контейнер базы данных вовсе не следует, что эта процедура будет выполняться физически именно на том компьютере, где храниться контейнер базы данных. Вовсе нет. FoxPro - это файл-сервер. Поэтому все процедуры всегда выполняются на клиенте (исключая написание COM-серверов). Как следствие, если одновременно с базой работают несколько человек из одного и того же филиала и у их компьютеров есть рассогласование в системных часах, то повтор значений по SYS(2015) - гарантирован. Sergey ChЯ столько жить не собираюсь, а Вы? "Я собираюсь жить вечно. Пока все идет по плану" (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 12:51 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
авторПри разных играх с системным временем и повышении быстродействия компьютеров, есть очень большая вероятность схлопотать повторяющееся значение Не есть вероятность, а уже приходилось нарываться на это ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 14:22 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
ВладимирМ Для начала, следует определиться, что для Вас важнее, объем данных или гарантированная уникальность этих самых данных... Объем, увы, имеет значение при передаче данных по нашим "скоростным" линиям связи... ВладимирМ Поэтому все процедуры всегда выполняются на клиенте (исключая написание COM-серверов)... Именно это и имелось ввиду, либо как альтернативу - написать что-то свое, чтобы данная процедура запускалась один раз (сложного тут ничего нет). ВладимирМ"Я собираюсь жить вечно. Пока все идет по плану" (с) Мне нравится Ваш подход к жизни ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 14:31 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Hi Sergey! Даже в случае COM сервера ЕСТЬ (хоть и малый, но пренебрегать не стоит) шанс получить дубликаты - если "массово" генерировать новые SYS(2015), потом достаточно быстро ПЕРЕЗАПУСТИТЬ твой процесс-генератор, то он начнёт отсчитывать с уже "пройденных" при предыдущем запуске величин. По сути SYS(2015) это основанный на DATETIME алгоритм (есть prg-ки на UT которые и генерируют его, и наоборот - "разбирают" на DateTime), НО чтобы его "приспособить" для быстрых компов, MS добавиль туда такую фишку, что если очень часто его вызывать (быстрее чем сменяется DATETIME - он вроде с точностью до сотых или тысячных секунды считается) - то фокс отходит от "основы" и просто начинает его банально наращивать на единицу за вызов - этим гарантируется "неповторение" В РАМКАХ ТЕКУЩЕГО ПРОЦЕССА - но из-за этого-же генерируемые значения уходят в "будущее", и если перезапустить процесс, то фокс снова пойдёт плясать от DATETIME и нарвёмся на "ранее сгенерированные" значения. Мне непонятно зачем ты его предложил - ибо если ЕСТЬ уникальный код филиала, то более чем приемлемо использовать NewID дополненный этим самым кодом филиала (причём если заранее "фиксировать" возможное число филиалов, то всё элементарно укладывается в одно Integer поле - просто умножаем NewID на "число филиалов" + Код_филиала - ну или наоборот - код_филиала*(2^31/"число филиалов") + NewID). Integer поле знимая всего 4 байта заведомо выигрышне чем SYS(2015) :) GUID же применим если например филиалы постоянно меняются (т.е. сложно заранее задать MAX(число_филиалов)), или если они появляются (методом почкования :) ) изначально БЕЗ связи с центральным сервером (т.е. у них пока НЕТУ кода филала, а работать уже нужно :) ) В общем-то это уже как-то обсуждалось - тут или на www.foxclub.ru... Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 21:36 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Igor Korolyov Как обычно - сколько людей, столько мнений и каждое имеет право на жизнь... И всегда интересно, как кто-то решает подобную задачу... Функцию sys(2015) применяю уже много лет и с оговоренными условиями проблем никогда не было. Как раз начал применять данное решение, когда не было никакой электронной связи между филиалами, а данные таскали дискеткой Конечно можно и Integer вместо sys(2015), но как Вы верно заметили - данная функция построено на времени и я ее использую, чтобы показать клиенту - когда "родилась" данная транзакция. Кроме того, я во многих случаях позволяю головной конторе вводить данные за филиал (при этом филиал видит эти чужие проводки)... и если брать Integer, то следующее значение надо высчитывать в отличии от sys(2015), что не всегда дешево... Короче это бесконечная история и путей решения очень много, как кто-то заметил:"Каждый программист баз данных должен написать в своей жизни репликацию..." P.S. Только не подумайте что я очень умный - многие вещи как правильно использовать sys(2015) я подсмотрел на уже упоминавшемся здесь UT... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2004, 23:53 |
|
||
|
как синхронизировать данные
|
|||
|---|---|---|---|
|
#18+
Hi Sergey! Если следовать твоим советам, то не совсем понятно как же ты восстанавливаешь дату из "обрезанного" SYS(2015) Потом ты ЯВНО пользуешься тем, что вероятность генерации дубля мала , но НЕ ИСКЛЮЧАЕШЬ её абсолютно (твой пример про ввод данных "от имени и по поручению" но в ДРУГОМ месте - на другом "генераторе"). А что касается "размера" - ты походу "упаковываешь" этот ID каким-то образом? Иначе я НЕ понимаю, почему 10 байт (SYS(2015)) по сравнению с 4-мя (Integer) тебя не смущают, а вот 10 байт по сравнению с 16-ю (GUID) уже изрядно напрягли :( Posted via ActualForum NNTP Server 1.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2004, 00:42 |
|
||
|
|
start [/forum/topic.php?fid=41&msg=32833713&tid=1595194]: |
0ms |
get settings: |
9ms |
get forum list: |
22ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
51ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
74ms |
get tp. blocked users: |
2ms |
| others: | 245ms |
| total: | 432ms |
| 0 / 0 |
