Добавить комментарий

Консолидации баз данных

В распределенной среде баз данных болевой точкой является синхронизация данных между базами. Убедиться в этом не сложно. Практически все задачи, в решении которых принимают участие люди, живущие в разных городах, страдают отсутствием аппарата синхронизации данных: копирования или репликации. Решения данной задачи могут быть получены при помощи, скажем, аппарата репликации Microsoft ( это отдельная тема, которую я обсасывал пару лет, работая в DocsVision); или простой выгрузки данных в файл (любимейшая тема 1С) и последующей загрузки данного файла в другую базу данных: или написанием своего модуля репликации (решаются обычно специфические задачи, но теряется, к сожалению, универсальность применения).

Во всем этом многообразии существуют свои плюсы и минусы, которых я не буду здесь касаться. Скажу просто, что я не видел до сих пор, чтобы аппарат репликации работал как операция drag&drop. Сложность понятна и очевидна для специалиста баз данных, потому что схема базы представляет в большинстве случаев жесткую конструкцию связей. Таблицы имеют большое количество строк, а приложения написаны таким образом, что не используют при работе групповых операций SQL запросов.

Вполне понятный для меня интерес привел к желанию реализовать операцию drag&drop для клиента nexus при решении задачи инвентаризации магазинов, находящихся в разных городах. После многократного продумывания задачи, я понял, что, запустив на своем компе два nexus клиента, подсоединенного к разным базам данных, я по существу, имею перед глазами решение задачи репликации или копирования данных (в данном случае репликация не по расписанию, а по желанию), если я соединю операцию drag одного клиента-источника и операцию drop второго клиента получателя, за которыми будет стоять получение данных из базы данных источника и запись этой информации в базу данных приемника.

Вот собственно некая преамбула, после которой я реализовал основной use case поставленной задачи. Остается описать, что в результате получилось. Итак на экране мы имеем два клиента, связанных с разными базами данных.

Особенностью текущей папки базы данных получателя является наличие документа «Настройки копирования», который описывает параметры соединения к базе данных источнику для текущей папки, когда в нее будет производиться операция drag&drop. Содержимое документа настройки представляет набор логически понятных полей, естественно зашифрованных и списка таблиц, которые можно просто отреплицировать.

Дальше все просто. Отмечаешь несколько объектов клиента источника и делаешь операцию drag

Далее тянешь мышью объекты и делаешь операцию drop:

Пользователь получает ясную и понятную картину действий и замечу за приемлемое время его ожидания.

Проанализируем, за счет чего сделан подобный механизм межбазовой передачи объектов.

Прежде всего, это отсутствие жесткой схемы базы данных в Nexus технологии. Введение различных ограничений и связей при синхронизации данных предъявляют счета, которые по стоимости времени выполнения операций копирования зачастую становятся неподъемными. Я не говорю, что от жесткой схемы базы данных необходимо полностью отказаться. У нее есть свои плюсы, но не здесь. Скорее всего, жесткая схема базы должна быть как одежда, которую носят только определенное время.

Второй момент связан с простотой nexus-объекта. Ведь по большому счету самый простой nexus-объекта равняется одной строке таблицы Docs. Это минимальное для объекта количество информации обеспечивает уникальную скорость обмена.

И наконец третий момент связан с простотой идентификации объекта в системе. Это простое число. Не uid, а int, что в 36 раз легче. Именно одно число на объект – это количество передачи в операции drag&drop. Можно, конечно, ставить задачи всемирной уникальности объектов, но насколько применение этого оправдано в практической сфере, сложно сказать.

Хотелось бы остановить внимание на реализации конструкции точки поворота (pivot-unpivot) для таблиц:

SELECT [name], [value]
FROM 
   (SELECT isnull(convert(varchar,[num]),'null') as [num],
		   isnull(convert(varchar,[status]),'null') as [status], 
		   isnull(convert(varchar,[substatus]),'null') as [substatus],
		   isnull(convert(varchar,[comment]),'null') as [comment],
		   isnull(convert(varchar,[started]),'null') as [started],
		   isnull(convert(varchar,[ended]),'null') as [ended],
  FROM [dbo].[materialg] 
    where UDN=2050) p
UNPIVOT
   ([value] FOR [name] IN 
      ([num],[status],[substatus],[comment],[started],[ended)
) AS unpvt

Все работает, но производительность падает на порядок, что приводит к отказу от применения подобных конструкций на практике. Спрашивается, зачем подобные рюшки нужны?

Бернс в переводе

Мое сердце в Шотландии, а вовсе не здесь
Оно там, в горах, несется как красная стрела,
Преследуя лань или косулю, в горах я весь,
Шотландия в моем сердце, куда б ни вела судьба.

Прощай же Шотландия, прощай северный край,
Здесь в стране достоинства родилась храбрость,
Где б я ни скитался и какой бы не видел Рай,
Горы Шотландии моя вечная любовь и радость.

18 октября 2009 года

Прикрепленный файлРазмер
Image icon nexus_conso_bd_01.jpeg78.93 KB
Image icon nexus_conso_bd_02.jpeg25.02 KB
Image icon nexus_conso_bd_03.jpeg25.37 KB
Image icon nexus_conso_bd_04.jpeg61.4 KB