Как объединить несколько баз данных Azure без прав для настройки внешних таблиц?

Question

В моей текущей настройке я подключаюсь к серверу Azure SQL Server с использованием Authentication = Active Directory - Integrated.Этот метод доступа разрешает доступ только к одной базе данных одновременно.Архитектура была перенесена из локальной среды SQL-сервера с изменениями, чтобы сделать облачную разработку возможной, но аналитика и отладка все же должны происходить в базах данных.Как правило, можно просто выполнить кросс-соединение баз данных с устаревшей конфигурацией SQL Server, возможно, с использованием серверов ссылок, если базы данных находятся на отдельных серверах.В облаке или лазури вы должны использовать Elastic search или избегать архитектурных решений, которые делают это необходимым.К исходным данным у меня есть только доступ на чтение, что является проблемой, поскольку вам необходимо разрешение ALTER ANY EXTERNAL DATA SOURCE , поэтому я думаю, что мне может понадобиться инструмент ETL для выполнения такого типа соединения, но мне интересноесли есть другие параметры или инструменты, позволяющие по существу выполнять кросс-базы данных или кросс-серверные объединения в Azure с доступом только на чтение.

Какие существуют идеи для выполнения этих типов объединений с доступом только на чтение?

Answer 1

Я надеялся, что ученый ответит на этот вопрос и скажет мне, что я был глуп, чтобы спросить, но вот мои нынешние мысли, может быть, это выведет ее ... путь вперед, как я вижу это ниже.

Учитывая только права на чтение, лучше всего сначала извлечь все данные из разных источников в среду, на которую у меня есть полные права разработки (например, сервер PostgreSQL или MySQL на локальном хосте, если он небольшой ... или, возможно, на одном месте разработки на Azure, которыйпредприятие допускает полное развитие прав).Создайте это в инструменте ETL, то есть в SSIS, и запустите, так как обновленные данные необходимы для любой дельты в источнике.Впоследствии выполните объединения на этих консолидированных данных.

Это имеет смысл, поскольку мне нужно поэкспериментировать с объединениями, имея дело с достаточно маленьким или передаваемым объемом данных, чтобы дублирование данных не являлось проблемой ресурсов и выполняло бы экспериментальные объединения непосредственно в SQLредактор вместо инструмента ETL.

Если бы у меня был намного больший набор данных, я бы попытался сэмплировать, выполнить то же упражнение, а затем, как только было понято соединение между серверами, выполнить его в масштабе в инструменте ETL, вероятнокаким-то периодическим способом, который в идеале мог бы быть в конечном счете выполнен параллельно.