Просмотр исходного текста страницы Сохранение в поток и репликация

Текущая версия Гедымина имеет два механизма по переносу (синхронизации) данных между базами:

* [[Репликация]];
* сохранение/считывание данных в поток.

Оба механизма имеют как ряд преимуществ, так и ряд недостатков. К преимуществам репликации можно отнести скорость, автоматическое логирование изменений и механизм разрешения конфликтов. Репликатор работает напрямую с базой данных и ничего не знает о бизнес-логике. Здесь же кроется и его главный недостаток: репликация возможна только на базах с одинаковой структурой. Точнее, базы должны иметь, как минимум, общую часть структуры, и после настройки репликации изменить структуру базы становится невозможно. Кроме того, репликация накладывает ряд ограничений на функционал. На базе с настроенной репликацией невозможно производить такие операции как «слияние», «создание настроек» и т.д. Необходимо также добавить, что репликация ведет логирование в базе данных, что несколько замедляет операции на изменение данных и увеличивает размер самой базы. Ну и, кроме того, на данный момент, репликация производится не встроенными средствами Гедымина, а отдельным программным средством. Следует также отметить, что репликатор требует определенных навыков работы, и сам механизм настройки репликации довольно громоздкий.

К преимуществам сохранения/загрузки данных из потока относится следующее:
* данная операция производится встроенными средствами Гедымина;
* потоки используют бизнес-объекты, что в свою очередь позволяет на этапе загрузке данных из потока изменить структуру базы. Именно поэтому данный подход лежит в основе создания/загрузки настроек.
* использование такого подхода делает возможным перенос данных между базами с различными структурами.

К недостаткам сохранения/загрузки данных из потока можно отнести низкую скорость, большой объем файла с переносимыми данными и, практически, отсутствие механизма разрешения конфликтов. Т.е. если мы загружаем в базу запись с уже существующим в базе РУИД-ом, и загружаемая запись имеет дату обновления позже, чем дата записи в базе, данные перезаписывается автоматически. Иначе пользователю выдается запрос на перезапись данных. К недостаткам можно также отнести то, что данный подход налагает на человека всю ответственность за то, какие данные будут перенесены. Имеется ввиду, что автоматическое логирование изменений, как в случае с репликацией, не ведется. И человек, создающий файл с обновлениями, полностью отвечает за его содержимое.

Оба подхода интересны и могут использоваться как дополнение друг другу. Однако бывают случаи, когда пользователи не хотят пользоваться репликацией для переноса данных между базами. Да и базы могут иметь различную структуру. Например, предприятие имеет несколько филиалов. Каждый филиал имеет свою специфику работы, но при этом время от времени они могут обмениваться между собой данными о клиентах. Возможны оба варианта: и настройка репликации только на часть базы, хранящую информацию о клиентах, и перенос данных между базами при помощи потоков. Если речь идет о полной синхронизации клиентской базы, репликация конечно предпочтительнее. Но, обмен информацией может иметь некие ограничения. Например, филиалу в Гродненской области вовсе незачем знать клиентов Минска. Тогда на помощь приходит сохранение информации в поток. Однако, если клиентов много, такая операция может занять часы.