Информация по обменам между информационными базами
Карандашов СергейПредисловие
Часто случаются ситуации, когда необходимо наладить обмен информацией между разными базами и каждый разработчик решает задачу в силу своего или чужого опыта. При этом не редко получаем неудовлетворительный результат по скорости или сложности доработки и анализа.
Далее список особенностей разных вариантов обмена только из личного опыта и некоторые субъективные сравнения.
Файловые форматы данных для обмена
XML - Очень гибкий формат, но в силу своей структуры имеет самые большие размеры и самую низкую скорость обработки. А если узким местом становится память или диск (для разных методов обаботки), скорость падает еще сильнее.
DBF - Не спорю, данный формат уже сильно устарел и во многих случаях его поддержка отменена. В этом виде с информацией скорость работы одна из самых высоких. Размеры файлов велики, как и в предыдущем случае, но скорость обработки просто потрясающая. К размеру требования тоже размытые, равно как и к используемой памяти (в зависимости от метода работы памяти может потребоватся совсем немного) и к диску.
Текстовый файл - Пожалуй, этот формат используют все молодые специалисты или не желающие тратить на работу с данными более 10 минут, остальные.
Если информацию пытаться структуировать, то в итоге получается адский труд как по времени, так и по сложности, да и отладка превращается в китайскую пытку. При чём чем информация более сложная по структуре, тем сложнее работать с данными и время разработки сильно увеличивается.
Другой вопрос, когда в текстовый файл идет информация, например, объекта метаданных, трансформированная в текст, время разработки минимальное. Но данный вариант удобен для временного хранения информации и применять его в рабочих проектах не приветствуется по всем параметрам.
Конвертация данных
Это самый распространённый обмен на сегодняшний день, позволяющий очень быстро создать правила конвенртации и так-же быстро автоматизировать обмен в обе стороны. При чем по автоматизации обмена написано много материалов, сводящиеся к вызову системых методов обработки “УниверсальныйОбменДаннымиXML”.
Организация, отдавшая предпочтение этому инструменту, получает самую широкую поддержку, т.к. по конфигурации КД есть и дополнительные курсы и вся необходимая литература. И, как следствие, очень много специалистов самого разного уровня, обладающих более менее стандартизированными знаниями. К тому-же в КД достаточно просто отлаживать обмен (3 уровня отладки и 1 специфичный и почти ни когда не пригодлается). Но вот с гибкостью и скоростью непосредственно обмена имеем серьёзные ограничения. Концепция конвертации данных основана на передачи всего списка объектов и служебной информации, даже если и нет необходимости. Например, при изменении договора во многих случаях передастся и контрагент, хотя он не менялся. Так-же КД передает информацию по принципу шприца - весь накопленный объём за один раз.
Рассматривать on-line обмен в данном разделе не буду, т.к. его тщательно не анализировал.
Связь через прямое соединение
Многие развивают связь на предприятии средствами прямого соединения между базами, используя средства интеграции и администрирования платформы 1С. При таком методе с первого взгляда одни плюсы, ведь работать в другой базе приходится как и в своей. Но при разработке начинают всплывать подводные камни, которые для многих оказываются непреодолимыми. Например, при интенсивном обмене информацией в реальном времени, для такого способа требуется мощное оборудование и постоянный контроль. Но всё равно удовлетворительной скорости и стабильности трудно добиться.
На платформе 8.1 разность по скорости между “Automation сервер “ и “Менеджер COM-соединений” у меня составила почти в 10 раз (!!!!!). Оно и должно было так быть, ведь в первом варианте запускается копия клиентского приложения, а во втором этого нет, поэтому на слабом компьютере разница столь велика. При этом во втором варианте сильно ограничен функционал, что тоже доставляет неприятности при разработке.
Связь через промежуточную СУБД
Данный вариант, пожалуй, самый оптимальный по скорости для критичных обменов, но имеет сложности в разработке и отладке. Принцип работы основывается на то, что каждая конфигурация, согласно описанным правилам, фиксирует изменения объектов и отправляет на сервер СУБД. Другая конфигурация с определённой периодичностью смотрит “посылку” в СУБД и при необходимости принимает её. Если при приёме нет нужного объекта (например, владельца), отсылается запрос на дополнительную передачу.
Когда мне была поставлена задача очень быстрого обмена я сделал инструмент, позволяющий производить обмен тремя вариантами: “Automation сервер, “Менеджер COM-соединений” и через промежуточную СУБД. На слабом компьютере, как не странно с большим отрывом зарекомендовал себя третий вариант. Но из-за сложности разработки его применять рекомендуется только для критичных задач к скорости. При чем если данных планируется не много, можно использовать даже SQLite, а если есть шанс получения большого объёма данных, то лучше смотреть в сторону PostgreSQL или MS SQL.
Прямая запись в СУБД базы
Это, пожалуй, самый быстрый способ передачи информации. Но тут разработка и поддержка очень дороги. Так-же высокая нагрузка на оборудование, ведь коннект необходимо держать постоянным и он установлен к рабочей базе (в предыдущем варианте обмен можно вынести вообще на другой слабомощный компьютер и поставить его в темнушку).
При любом измении конфигурации и некоторых обновлений платформы, необходимо анализировать изменения структуры БД и по ситуации действовать дальше. Когда в конфигураторе 1С что-то меняется не задумываясь, в БД иногда приходится работать прилично. При чем специалисты по, например, MS SQL стоят дополнительных денег, которые должны обладать знаниями шире чем select, update и delete.
Всё выше описанное только личный опыт и опыт команд, в которых работал. Если-бы данная информация была у меня лет десять назад, многих ошибок бы не совершал.
