Каковы проблемы с соединением между двумя таблицами в двух разных базах данных?

Меня интересуют ваши мысли о ловушках объединения двух или более таблиц из разных баз данных. Я попытаюсь привести пример.

Предположим, что таблица Table1 находится в базе данных DatabaseA, а Table2 находится в DatabaseB. Скажем, у меня есть представление, в DatabaseA, которое вытаскивает некоторые данные из Table1 и некоторых других таблиц в DatabaseA '.

Это представление используется для перемещения данных в другую базу данных, позвольте этому, unimaginatevely, DatabaseC.

Если мне нужны данные из Table2, мой инстинкт состоит в том, чтобы напрямую присоединиться к Table2 в этом представлении, вроде как table1 inner join DatabaseB..table2 on [some columns]

Делать это довольно просто и быстро, но у меня в голове головокружительный голос, который говорит мне, чтобы я этого не делал. Мои заботы состоят в том, что мы не можем отслеживать все объекты в зависимости от Table2, поэтому, если я что-то меняю, я должен быть очень осторожным и помнить всюду, где я использую эту таблицу. Итак, вроде как разрыв SRP для этого представления (и двух баз данных), потому что это представление может меняться от двух разных действий (выполняется в двух разных базах данных: Изменение Table1 или изменение Table2)

Меня интересуют ваши мнения. Это хорошая или плохая идея? Каковы были бы проблемы с этим подходом (умение работать мудро, поддерживать мудрость и т.д.), И если у вас есть реальный мировой опыт, когда этот подход либо был большой ошибкой, либо был спасателем жизни для вас.

P.S: Я искал эту тему в google и SO, но не смог найти ничего подобного. Я с радостью возьму минус голоса, дублирую вопросы и другие "выговоры" от пользователей SO, чтобы иметь другое представление об этой проблеме.

P.P.S: Я использую SQL Server 2005.

Спасибо и надеюсь, что я убедился:)

Ответ 1

Если они находятся на одном сервере, нет реальной проблемы, связанной с отдельной базой данных. Фактически, вы можете отделить их по уважительным причинам. Например, если у вас есть комбинация транзакционных таблиц и таблиц поиска, которые импортируются из файлов. Транзакционные данные нуждаются в полном восстановлении и частых резервных копиях журналов транзакций, чтобы иметь возможность правильно восстанавливать, данные поиска не могут и могут быть полезны в базе данных в простом режиме восстановления.

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

Теперь, когда базы данных находятся на разных серверах, может возникнуть проблема с производительностью, и получение данных будет более сложным.

Ответ 2

Как и все остальное в SQL, это зависит.

На моей работе мы делаем это много. У нас очень большие наборы данных и отдельные базы данных для записей заголовков и уровней детализации, затем дополнительные БД для отчетов или таблиц, которые мы собираем из других данных и т.д. И т.д.

Нет проблем с производительностью при подключении к БД, а в некоторых случаях в зависимости от настроек вашего оборудования это может быть FASTER. Если DatabaseA и DatabaseB находятся на отдельных физических дисках с разными контроллерами, скорее всего, будет быстрее запускать запрос, соединяющий их, чем если бы они находились в одной и той же БД на том же томе.

Обслуживание может быть проблемой, но не более, чем для любой другой базы данных/таблиц. Это не похоже на то, что у вас разные версии одних и тех же таблиц, у вас есть только эти таблицы в разных БД.

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

Ответ 3

Ваш головокружительный голос, вероятно, прав.

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

Но если вас это не волнует, я не вижу проблемы: -)

Ответ 4

Ответ на ваши вопросы... это зависит.

Я заметил, что нет серьезной деградации производительности, когда вы сохраняете запросы красивыми и простыми (меньшее количество соединений и т.д.).

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

Оптимизатор в конечном итоге получает решение о том, как выполнить запрос. Чем сложнее запрос, тем больше возможностей для оптимизатора получить порядок операций "неправильный".

Недавно я экспериментировал с этой проблемой...

Я выполнил запрос с примерно 8 соединениями в одной базе данных. Затем я разместил копию этой базы данных на том же сервере с другим именем, а затем я изменил запрос, чтобы он присоединился к парам таблиц во второй копии базы данных.

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

Перекрестная база данных соединяет запрос с запросом чуть менее 3 минут.

enter code here

Ответ 5

Некоторые общие темы перекрестных подключений базы данных:

Внешние ключи

Как отмечали другие, при отсутствии внешних ключей вам необходимо свернуть свою ссылочную целостность. Не проблема сама по себе, но проблемы могут возникать, когда вы не контролируете данные в одной или нескольких базах данных.

Связанная проблема связана с использованием инструментов CASE. При обратном проектировании схемы они будут игнорировать ссылки между таблицами, где отношения FK- > PK не существуют.

Производительность

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

Сцепление

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

Изменение данных

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

Все это, правда, существует много случаев, когда объединение кросс-баз данных является нормой. Несколько примеров, которые я видел:

Март-Repository

Операции выполнения выполняются на мастере, в то время как хранимый файл хранится в репозитории. Операции CRUD происходят между ними на частой или нечастой основе (ночное обновление, в реальном времени и т.д.).

Legacy DB

Вы можете предоставить устаревшую базу данных для переноса данных и/или создания отчетов/аудита.

Поиск

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

Итак, чтобы ответить на ваш вопрос - это зависит от того, что именно вы делаете, и является ли риск приемлемым. Существуют и другие решения, такие как репликация, но опять же, насколько это возможно, будет зависеть от структуры вашего отдела/компании.