Независимо от наличия или отсутствия корпоративных стандартов на предприятии разнообразие способов хранения и представления информации обусловлено рядом объективных обстоятельств, в частности, эволюционным характером развития информационной системы предприятия, например: табличный процессор -> персональная СУБД -> настольный (на 5-10 клиентов) БД-сервер -> полнофункциональный мощный сервер баз данных. При этом каждый следующий виток прогресса, как правило, не означает разрушение до основания старой системы во имя построения новой, какой бы производительной и масштабируемой она ни обещала быть. Перефразируя известное высказывание о душе математика, можно сказать, что за душу каждого программиста борются ангел бесконечного совершенства и дьявол здорового консерватизма. В любом случае внедрение новой технологии - процесс далеко не одномоментный, и в течение переходного периода необходимость максимально мирного сосуществования старых и новых форматов хранения в рамках одной информационной системы не вызывает сомнений. Более того, в подавляющем большинстве случаев унаследованные приложения не умирают бесследно, а продолжают тихо доживать свой век на каких-нибудь узкоспециализированных локальных задачах, данные из которых тем не менее должны быть доступны нашей комплексной современной и перспективной системе.
Другой вариант развития событий. Есть задача З1, для которой покупается решение фирмы Ф1 на платформе БД1. Через некоторое время возникает задача З2, которой фирма Ф1 не занимается, но под которую есть решение у фирмы Ф2, только вот беда - производится оно на БД2 и ни на чем ином. Повздыхали, конечно, но делать нечего - купили. Так понемногу у нас на предприятии вместе с решениями собирается изрядный зоопарк СУБД. А спустя еще некоторое время появляется новая задача З3, которой на входе требуются данные из БД1, БД2 и т.д., и вместо программирования бизнес-логики, разработчики вынуждены решать проблемы доступа к разнородным форматам данных.
Я думаю, приведенные примеры наверняка до боли знакомы большинству программистов, администраторов и IT-менеджеров. Разумеется, ими не исчерпываются все возможные сценарии, однако этого вполне достаточно для того, чтобы существование и актуальность проблемы интероперабельности различных систем управления данными считать доказанным. В сложившейся ситуации наиболее привлекательным и экономичным решением оказывается продукт, способный работать с данными любой природы независимо от их формата и места хранения. Этому требованию удовлетворяет Microsoft SQL Server 7.0, взаимодействующий как с собственным, так и с внешними механизмами хранения с помощью технологии универсального доступа OLE DB. Однако предметом нашего сегодняшнего разговора будет не сама технология OLE DB (предполагается, что слушателям она в той или иной степени известна), а ее реализация в Microsoft SQL Server 7.0 и открывающиеся в связи с этим возможности перед разработчиками гетерогенных серверных приложений.
Если отнести DTC-транзакции к тиражированию с максимально плотной (по протоколу двухфазной фиксации) целостностью, я бы выделил на стороне сервера три основных способа построения распределенных приложений - это тиражирование, службы преобразования данных (Data Transformation Services - DTS) и распределенные запросы. Все они логически связаны друг с другом: например, службы преобразования данных можно рассматривать как разновидность тиражирования мгновенных снимков данных (snapshots), а пакет DTS или шаг пакета может выступать в роли прилинкованного сервера. Каждый из них может в той или иной мере использоваться в реальных приложениях в процессе построения хранилищ данных при сборе и консолидации информации из внешних и распределенных OLTP-источников, однако наиболее яркая роль здесь безусловно принадлежит службам преобразования данных.