| Синхронизация баз данных или Данные off-line. |
Уважаемые коллеги. Хочу предложить тему, которая, думаю, будет интересна тем, кто
занимается
базами данных, особенно в промышленном масштабе. Тему можно обозначить примерно как
"Синхронизация баз данных" или "Данные off-line". Попробую смоделировать некую
условную
абстрактную задачу, которую можно спроецировать на конкретную ситуацию.
Пусть существует некий главный склад, отгружающий продукцию, оснащенный IT-системой
контроля
отгрузки, ведения учета и т.п. Пусть существует некий удаленный филиал, который также
занимается
оформлением отгрузки с главного склада, и у которого имеется точно такая же
IT-система. Связь on-line
отсутствует в силу каких-либо причин - технических, экономических, политических и
т.д. :o) В каждой
IT-системе производятся независимые и раздельные по времени манипуляции с данными.
Требуется
обеспечить надежную синхронизацию данных между двумя системами, неважно, каким
способом -
посредством дискет, разовым соединением модемами и т.д. Проблемы видятся следующие:
1) Отслеживание добавления/изменения/удаления данных в каждой копии данных
Если добавление/удаление можно достаточно надежно синхронизировать, то при модификации
имеющихся данных возникает проблема "первородности" изменений, т.е. принятие решения
о том,
которое из изменений какого поля является наиболее объективным.
2) Объективная модификация каких-либо счетчиков, например, счетчиков отгружаемой
продукции.
Поясняю - если в обеих копиях данных был организован декремент счетчика продукции на
1, при
неизменности других полей записи, то в синхронизированной записи должен быть
произведен
окончательный декремент уже на 2.
3) Проблема возрастания сложности синхронизации между тремя и более копиями данных
(ведь
филиалов может быть несколько)
4) Невозможность проводить анализ изменений по штампам времени, т.к. нет
синхронизации часов
между компьютерами. Эта проблема только кажется несерьезной, на самом деле китайские
"мамы"
и чайниковость пользователей создают массу проблем с отметками времени.
?) Ваши дополнения о возможных проблемах такого рода систем.
Интересны мнения о возможных моделях построения такой off-line системы. В том числе,
и симбиоз
с on-line системой для обеспечения общей работоспособности системы при неполадках
связи on-line.
Я попробовал рассчитать некие дополнительные "журналирующие" таблицы. Т.е., имется
запись,
одинаковая во всех копиях данных, а все изменения заносятся в журнал без ее
модификации. Для
работы пользователям выдается "виртуальная" запись, собранная на основе журнала. Но
это очень
неэффективно по скорости плюс пункт 4 из описания возможных проблем. Что касается
SQL-сервера,
то с точки зрения надежности, минимума ресурсоемкости и минимального администрирования
предпочтение было отдано серверу InterBase. Кстати, было бы интересно узнать о
принципах работы
версионности этого сервера, этот механизм может быть неплохим вариантом для
частичного решения
моей проблемы. Андрей Омутов
Всего в теме 33 сообщения
Добавить свое сообщение
Отслеживать это обсуждение  <<<... | 13—4 | 3—1
Всего сообщений в теме: 33; страниц: 4; текущая страница: 4
| № 3 10-01-2001 15:54 |   |
Это вопрос для круглого стола.
| № 2 10-01-2001 15:10 | |
Подобная тема активно обсуждалась в fido.su.dbms
Основным выводом было то, что репликация бывает физическая и логическая.
Первая работает на большинстве промышленных СУБД в том числе и в двунаправленом режиме.
Вторая - репликация с учетом семантики данных. В частном случае задача разрешима, например, использованием т.н. естественных ключей. А в общем случае, действительно, задачка для НИИ ;-)
| № 1 10-01-2001 14:43 | |
Хорошая тема.... К тому же задача поствлена очень актуально, у нас в России как раз это очень большая проблемма, потому что установить качественную связь между филиаломи не всегда возможно. а зачаствую руководство не видит в этом необходимости. это не его головная больни синхронизация дпнных, они индинтичны быть должны, а каким образом это думать тебе.
Но, есть одно большое но.... Эта темя не для конференции, над такой ткматикой бьються крупные фирмы, и отделы бывших НИИ. Поговорить, пообсуждать конечно можно, даже нужно, к сожалению мы тут не найдем решение. и даже не выбирем направления развития...
<<<... | 13—4 | 3—1
Всего сообщений в теме: 33; страниц: 4; текущая страница: 4
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
|
