Факт использования одинаковой СУБД (например, SQL) не определяет безусловную возможность интеграции, а факт неиспользования - безусловную невозможность.

Часто говорят, что если база данных, с которой надо взаимодействовать, "стандартная" или, еще один таинственный термин, "открытая", то в нее очень легко "прямо брать и писать" или "просто читать" оттуда. Конечно, реализовать это можно. Но это категорически неверно. Внутреннее устройство любой программы - компетенция исключительно ее разработчиков. Их святое право - в любой момент изменить, как структуру данных, так и алгоритмы интерпретации этих данных. Повторимся, в любой момент и без уведомления кого бы то ни было. Совершенно иной подход должен быть к модификации интерфейсных (включая межпрограммное взаимодействие) процедур - необходимо предварительное согласование и уведомление о внесении документированных изменений с определенной даты.

Рассмотрим пример. Технология передачи налоговой отчетности в ИФНС, ПФР и т.д. В нашем государстве было бы нетрудно "построить" налогоплательщиков и велеть им установить SQL (или Oracle или еще что-нибудь - не важно) для интеграции с ИФНС и заставить их купить какой-нибудь продукт, который записывает налоговую отчетность прямо в SQL-хранилище данных непосредственно в Министерстве финансов  РФ. Однако этого не сделано. Вместо этого прописан открытый (важно: "открытый" - значит известный, кому положено, опубликованный, где положено, в том объеме, в котором требуется. Термин "открытый" никак не означает, что это реализовано компанией Майкрософт, а не, скажем, Полак АйТи) формат данных для обмена с ИМНС (ПФР) и определены открытые процедуры (порядок, регламент, разграничение ответственности) формирования, передачи и подтверждения такого обмена. Самая главная проблема межпродуктового взаимодействия - не разные физические форматы данных - а регламенты взаимодействия.

Рассмотрим еще пример. АСКОП - автоматизированная система оплаты проезда (в общественном транспорте). Требуются справочники расписаний, персонала, тарифов и т.д. Учитывая назначение системы, должны они там заводиться? Нет. Где должны? Например, в АвтоПарк. Согласовал ли кто-то структуру данных с АвтоПарк (1С , SAP, MS Dynamics или любой другой системой уровня предприятия)? Нет. Предоставил ли кто-то документированный регламент передачи справочников в АСКОП из систем уровня предприятия? Нет. Кого интересует, SQL ли там или примитивный текстовый файл, если нет никакого способа,  документированного человеческим языком, синхронизации справочников из системы уровня предприятия с системой АСКОП. Результат: работники предприятия колотят справочники в две, как минимум, системы. Но, возможно, кто-то скажет, что таких проблем не было бы вовсе, если бы система уровня предприятия использовала SQL (если бы она, вдруг, была построена на другой стандартной платформе, например, Oracle , то пока неизвестно, что нужно было бы делать). Предположим, что АвтоПарк работает на MS SQL. В АвтоПарк есть расписание (а где еще ему быть?). Систему АСКОП научили (ее разработчики) "смотреть" в базу данных АвтоПарк в таблицы с расписанием и персоналом и все оттуда брать. Мечта сбылась. В один прекрасный день пользователи АвтоПарк создали новый выход. Система АСКОП "посмотрела" в базу данных АвтоПарк, и получила, что хотела, и стала "пользоваться". Важное замечание - разработчики АвтоПарк не знают - как и чем. Через неделю пользователи АвтоПарк нашли ошибки в описании выхода, предположим, сочли, что выход вообще зря завели. И удалили его - а зачем он, если его зря ввели. Конечно, просто так выход удалять нельзя, нужно, чтобы путевые листы были перетаксированы, наряд изменен и т.п. Конечно, АвтоПарк это контролирует и обеспечивает все предусловия для корректного удаления выхода из справочника. Но о системе АСКОП они не знают ничего, потому что такова парадигма - "открытая база" - "смотри, кто хочет, делай, что хочешь". Получили систему АСКОП с информацией в справочнике о несуществующих в реальной жизни объектах. Что будет дальше? Никто не знает...

Создать интегрированную систему управления всем невозможно, и появляются другие продукты, например, система АСКОП. Образно говоря, разные продукты существуют для того, чтобы каждый возился у себя на кухне и не думал про устройство других кухонь. А межкухонный обмен должен производится не фаршем в мисках, а продуктами в товарных упаковках, в переводе на язык IT - в соответствии с (открытым) стандартом и регламентом. Почему-то в "обычном", некомпьютерном мире никого не удивляют подобные процедуры - упаковывание, складирование, стандартизация, паллеты, бухты, коробки, контейнеры, терминалы, заказы, счета, накладные. Почему-то никто не едет на цементный завод за 2487 килограммами цемента, который насыпают прямо ковшом экскаватора в самосвал. Зачем-то упаковывают в мешки по 50 килограмм, те потом в паллеты, контейнеры. Затем все это привозят на стройку и в обратном порядке распаковывают, мешки приходится куда-то выбрасывать и т.д., остаются излишки, короче говоря, одни "лишние" проблемы. Но всем понятно, что так все и должно быть, а иначе работать не будет. В мире IT обычные люди и даже некоторые из тех, кто называет себя специалистами, почему-то мечтают о каком-то хранилище, из которого каждый будет "черпать" что захотел! Честное слово, это какой-то новый миф Древней Греции!

Уместно вспомнить один пример того, как сделано упорядочивание информации - пусть не в компьютере, а на бумаге, но информации! Почему в некомпьютерном документообороте существует приказ о приеме на работу? Ведь можно просто вписать в книгу личного состава строку с новым работником (а при увольнении стереть её ластиком или замазать замазкой, чтобы впоследствии вписать туда принятого на вакантную должность), и порядок. Но ведь придумали же документооборот, чтобы можно было в любой момент свести концы с концами. Догадались писать приказ о приеме на работу под копирку в 5 экземплярах (в отдел кадров, в ВУС, в бухгалтерию, в архив, в цех). Специалист по информации должен назвать это движение бумаги так - технология синхронизации справочников. В бухгалтерии был свой справочник. Им дела не было до, например, того, в какой именно бригаде работает слесарь. А в цехе плевать хотели, платит ли он алименты. В ВУС интересовались военной специальностью и возрастом, а также степенью годности к службе, которая в свою очередь, была безразлична бухгалтерии и цеху. Для внесения новой (или исключения ненужной) записи в справочник (книгу) в цехе использовали приказ, т.е. документ о внесении (исключении) в/из справочник(а). И, если, например, после увольнения работника, в цехе про него можно забыть и вычеркнуть из книги, то в бухгалтерии запись о нем должна остаться на 70 лет.

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

Внутри интегрированной системы (например, АвтоПарк) нет нужды в синхронизации справочников с одними и теми же данными. Но, повторимся, создать интегрированную систему управления всем невозможно, и появляются другие продукты, например, система АСКОП. Вот тут самое время вспомнить о том, что уже было придумано в эру гроссбухов для синхронизации справочников цеха и бухгалтерии - документы (электронные) и регламенты обмена ими (отраженные в алгоритмах). Как видно, СУБД здесь совсем не при чем, так как стандартизации подлежат только форматы документов и регламенты их обмена. Другого пути интеграции программных продуктов не существует. Вернее, существует, и много, но они не ведут к успеху.