Сохранение в поток и репликация - История изменений

SYSDBA в 10:42, 21 августа 2009

2009-08-21T10:42:42Z

SYSDBA в 20:28, 13 января 2007

2007-01-13T20:28:50Z

SYSDBA в 20:21, 13 января 2007

2007-01-13T20:21:29Z

SYSDBA в 20:20, 13 января 2007

2007-01-13T20:20:59Z

Новая страница

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

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

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

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

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

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

← Предыдущая		Версия 10:42, 21 августа 2009
Строка 19:		Строка 19:

	'''By JT'''		'''By JT'''
		+
		+	[[Category:Репликация]]

← Предыдущая		Версия 20:21, 13 января 2007
Строка 14:		Строка 14:

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

@@ Строка 4: / Строка 4: @@
 * сохранение/считывание данных в поток.
-Оба механизма имеют как ряд преимуществ, так и ряд недостатков. К преимуществам репликации можно отнести скорость, автоматическое логирование изменений и механизм разрешения конфликтов. Репликатор работает напрямую с базой данных и ничего не знает о бизнес-логике. Здесь же кроется и его главный недостаток: репликация возможна только на базах с одинаковой структурой. Точнее, базы должны иметь, как минимум, общую часть структуры, и после настройки репликации изменить структуру базы становится невозможно. Кроме того, репликация накладывает ряд ограничений на функционал. На базе с настроенной репликацией невозможно производить такие операции как «слияние», «создание настроек» и т.д. Необходимо также добавить, что репликация ведет логирование в базе данных, что несколько замедляет операции на изменение данных и увеличивает размер самой базы. Ну и, кроме того, на данный момент, репликация производится не встроенными средствами Гедымина, а отдельным программным средством. Следует также отметить, что репликатор требует определенных навыков работы, и сам механизм настройки репликации довольно громоздкий.
+Оба механизма имеют как ряд преимуществ, так и ряд недостатков. К преимуществам репликации можно отнести скорость, автоматическое логирование изменений и механизм разрешения конфликтов. [[Репликатор]] работает напрямую с базой данных и ничего не знает о бизнес-логике. Здесь же кроется и его главный недостаток: репликация возможна только на базах с одинаковой структурой. Точнее, базы должны иметь, как минимум, общую часть структуры, и после настройки репликации изменить структуру базы становится невозможно. Кроме того, репликация накладывает ряд ограничений на функционал. На базе с настроенной репликацией невозможно производить такие операции как «слияние», «создание настроек» и т.д. Необходимо также добавить, что репликация ведет логирование в базе данных, что несколько замедляет операции на изменение данных и увеличивает размер самой базы. Ну и, кроме того, на данный момент, репликация производится не встроенными средствами Гедымина, а отдельным программным средством. Следует также отметить, что репликатор требует определенных навыков работы, и сам механизм настройки репликации довольно громоздкий.
 К преимуществам сохранения/загрузки данных из потока относится следующее:
@@ Строка 11: / Строка 11: @@
 * использование такого подхода делает возможным перенос данных между базами с различными структурами.
-К недостаткам сохранения/загрузки данных из потока можно отнести низкую скорость, большой объем файла с переносимыми данными и, практически, отсутствие механизма разрешения конфликтов. Т.е. если мы загружаем в базу запись с уже существующим в базе РУИД-ом, и загружаемая запись имеет дату обновления позже, чем дата записи в базе, данные перезаписывается автоматически. Иначе пользователю выдается запрос на перезапись данных. К недостаткам можно также отнести то, что данный подход налагает на человека всю ответственность за то, какие данные будут перенесены. Имеется ввиду, что автоматическое логирование изменений, как в случае с репликацией, не ведется. И человек, создающий файл с обновлениями, полностью отвечает за его содержимое.
+К недостаткам сохранения/загрузки данных из потока можно отнести низкую скорость, большой объем файла с переносимыми данными и, практически, отсутствие механизма разрешения конфликтов. Т.е. если мы загружаем в базу запись с уже существующим в базе [[РУИД]]-ом, и загружаемая запись имеет дату обновления позже, чем дата записи в базе, данные перезаписывается автоматически. Иначе пользователю выдается запрос на перезапись данных. К недостаткам можно также отнести то, что данный подход налагает на человека всю ответственность за то, какие данные будут перенесены. Имеется ввиду, что автоматическое логирование изменений, как в случае с репликацией, не ведется. И человек, создающий файл с обновлениями, полностью отвечает за его содержимое.
 Оба подхода интересны и могут использоваться как дополнение друг другу. Однако бывают случаи, когда пользователи не хотят пользоваться репликацией для переноса данных между базами. Да и базы могут иметь различную структуру. Например, предприятие имеет несколько филиалов. Каждый филиал имеет свою специфику работы, но при этом время от времени они могут обмениваться между собой данными о клиентах. Возможны оба варианта: и настройка репликации только на часть базы, хранящую информацию о клиентах, и перенос данных между базами при помощи потоков. Если речь идет о полной синхронизации клиентской базы, репликация конечно предпочтительнее. Но, обмен информацией может иметь некие ограничения. Например, филиалу в Гродненской области вовсе незачем знать клиентов Минска. Тогда на помощь приходит сохранение информации в поток. Однако, если клиентов много, такая операция может занять часы.
 '''By JT'''