|
|
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Есть некая реляционная локальная БД, неважно какая. В ней таблицы, все они имеют уникальный id и name (строка). id всегда уникальное для всех таблиц. К БД есть локальное клиентское приложение, которое пишет и читает БД локально. Необходимо синхронизировать периодически все эти БД (таблицы синхронизируются по полю name). ИНТЕРЕСУЕТ АЛГОРИТМ СИНХРОНИЗАЦИИ ВСЕХ ЭТИХ БД! Желательно такой алгоритм, который исключает потерю и искажение данных. Можно привести несколько вариантов, если такие имеются. Их плюсы, минусы. Сейчас тупо отслеживаю дату и время изменения, добавления, удаление записей. Но как то все это громозко и не красиво! Пример, как только не запутывал dropbox, ан нет, все правильно синхронизирует. Надежно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 20:20 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
wowow, Предполагается ли делать UPDATE в этой базе? Или только SELECT + INSERT+DELETE ? wowowПример, как только не запутывал dropbox, ан нет, все правильно синхронизирует. Надежно.Повезло. Или показалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 20:27 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
miksoftwowow, Предполагается ли делать UPDATE в этой базе? Или только SELECT + INSERT+DELETE ?. UPDATE будет конечно же. Обязательно, хотя предположу что можно удалять и добавлять в случае update. Но это опять же кривовато, хотя опять же приложение mail.cloud update делает только в новых версиях, а так до этого через удаление - добавление! Облачные клиенты (dropbox, cloud.mail и т.д.) привожу только в качестве примера. У меня же учетная система. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 20:33 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
wowowUPDATE будет конечно же.Тогда абстрактного идеального алгоритма не существует. Будет нужно разбирать коллизии правок (т.е. когда правки одного объекта происходят одновременно в разных местах). Для чего нужно знание предметной области этих объектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 20:37 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
wowowИНТЕРЕСУЕТ АЛГОРИТМ СИНХРОНИЗАЦИИ ВСЕХ ЭТИХ БД!Бери больше, кидай дальше, только надо предусмотреть либо контроль версий + 3-way merge, либо флажки "эта запись с такого-то момента времени редактируется таким-то клиентом" и 2-way merge, либо "контроль версий для бедных", когда приложение зовёт хранимку, и отдаёт ей и исходные и изменённые юзером значения полей, а хранимка делает 3-way merge текущего состояния строки в таблице БД, исходных значений полей и изменённых значений полей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 21:32 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
iv_an_ruwowowИНТЕРЕСУЕТ АЛГОРИТМ СИНХРОНИЗАЦИИ ВСЕХ ЭТИХ БД!Бери больше, кидай дальше, только надо предусмотреть либо контроль версий + 3-way merge, либо флажки "эта запись с такого-то момента времени редактируется таким-то клиентом" и 2-way merge, либо "контроль версий для бедных", когда приложение зовёт хранимку, и отдаёт ей и исходные и изменённые юзером значения полей, а хранимка делает 3-way merge текущего состояния строки в таблице БД, исходных значений полей и изменённых значений полей. Ок. Как то это все геморройно... У 1с 7.7 например, есть бд, затем в любой момент, подчеркну в любой момент ее можно перевести В распределенную бд и все синхронизируется! И предметная область тут ни причем! Как то же они сделали так! Вот и спрашиваю может метода какая есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 21:56 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
wowowЕсть некая реляционная локальная БД, неважно какая. Вот с этого момента - всё неправильно. Если тебе не важно какая локальная БД то мы тебе и дадим не важно какие советы под неважно какие условия. Вобщем делай триггеры на все таблицы и т.д. Короче, пилите Шура... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 23:05 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
wowowiv_an_ruпропущено... Бери больше, кидай дальше, только надо предусмотреть либо контроль версий + 3-way merge, либо флажки "эта запись с такого-то момента времени редактируется таким-то клиентом" и 2-way merge, либо "контроль версий для бедных", когда приложение зовёт хранимку, и отдаёт ей и исходные и изменённые юзером значения полей, а хранимка делает 3-way merge текущего состояния строки в таблице БД, исходных значений полей и изменённых значений полей. Ок. Как то это все геморройно... У 1с 7.7 например, есть бд, затем в любой момент, подчеркну в любой момент ее можно перевести В распределенную бд и все синхронизируется! И предметная область тут ни причем! Как то же они сделали так! Вот и спрашиваю может метода какая есть?Есть. Использовать распределённую БД. Понимаете, СУБД --- это не столько способ собрать все данные в одно место, сколько способ собрать все геморрои в одно место. Вместо того, чтобы заставлять апп-девелоперов разбираться с геморроями в каждой отдельной клиентской программе (и разбираться с ошибками, в силу недостаточной квалификации), геморрои переносятся меньшей частью в немногочисленные хитрые хранимки, где с ними разбираются специально обученные люди, а большей частью --- в движок СУБД, где с ними раз и навсегда разбираются ещё более обученные люди. Как только вы начинаете вешать на клиентское приложение хотя бы часть функций СУБД, вы начинаете процесс обратного переноса геморроев из БД в приложения. Ваша задача --- прочитать, что такое распределённые транзакции и DTS, что такое репликация "публикатор--подписчики", что такое транзакционная репликация, и что такое двусторонняя репликация, выбрать более подходящий метод из поддердиваемых вашей СУБД, и сделать, как велит документация. Всё. Не надо пытаться сделать свой велосипед, это очень дорого. А именно: если описание алгоритма занимает в Дейте N страниц, то заметно более квалифицированный, чем вы, специалист ухлопает на это от N до N^2 месяцев. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2014, 23:48 |
|
||
|
Алгоритм синхронизации БД
|
|||
|---|---|---|---|
|
#18+
Принципиально существует три способа репликации: 1) Клонирование (применимо только если редактируется исключительно одна копия) 2) Log Shipping (нужен хоть какой-то способ CDC) 3) Merge (прямая пропорциональность объёма работы от объёма БД) Каждый их этих способов имеет свои достоинства и недостатки. Для сферических коней в вакууме абстрактных БД обычно используется log shipping, как наиболее универсальный способ (если, конечно, СУБД вообще позволяет организовать CDC хоть каким-то образом). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.01.2014, 16:25 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=38531066&tid=1341497]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
211ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
56ms |
get tp. blocked users: |
1ms |
| others: | 240ms |
| total: | 551ms |

| 0 / 0 |
