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

Question

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

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

Это представление используется для передачи данных в другую базу данных, давайте назовем это однозначно 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.

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

Answer 1

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

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

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

Answer 2

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

На моей работе мы делаем это МНОГО.У нас есть очень большие наборы данных и отдельные БД для записей на уровне заголовка и детализации, затем дополнительные БД для отчетов или таблиц, которые мы строим из других данных и т. Д. И т. Д.БД, а в некоторых случаях в зависимости от настроек вашего оборудования это может быть БЫСТРО.Если DatabaseA и DatabaseB находятся на отдельных физических дисках с разными контроллерами, скорее всего, будет быстрее выполнить запрос, объединяющий те, что, если бы они находились в одной и той же БД на одном и том же томе.больше, чем для любой другой базы данных / таблиц.Не то, чтобы у вас были разные версии одних и тех же таблиц, у вас просто есть эти таблицы в разных БД.

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

Answer 3

Ваш ворчащий голос, вероятно, прав.

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

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

Answer 4

Некоторые общие темы, касающиеся объединений между базами данных:

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

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

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

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

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

Соединение

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

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

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

---

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

Mart-Repository

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

Legacy DB

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

Lookup

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

---

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

Answer 5

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

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

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

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

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

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

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

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

enter code here