Хорошо, давайте разберемся с этим:
- Как строятся соединения между двумя таблицами в нескольких базах данных? (Пример кода здесь будет полезен).
Это довольно просто. Объекты SQL имеют соглашение от 1 до 4:
Servername.databasename.schemaname.tablename
Если все ваши таблицы находятся на одном сервере в одной базе данных с одним владельцем / схемой, вы можете просто проигнорировать первые три части и использовать то, к чему вы больше всего привыкли:
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
Если одна из ваших таблиц находится в другой базе данных и обе используют схему по умолчанию для своих баз данных, то вы просто добавляете базу данных во вторую таблицу:
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Если вы оказались в третьей базе данных, отличной от той, которую вы запрашиваете, вы явно используете оба имени базы данных:
Select a.*,b.* from
databaseD..tableA a inner join
databaseC..tableB b on a.col1 = b.col1
Если вы используете разные схемы и / или владельцев, вы можете добавить их в:
Select a.*,b.* from
databaseD.john.tableA a inner join
databaseC.accounting.tableB b on a.col1 = b.col1
И, наконец, если вы очень осторожны и имеете веские причины, вы можете присоединиться к (обычно небольшой) таблице на другом сервере:
Select a.* from
databaseD.john.TableA a inner join
ATLANTA.databaseC.accounting.tableB b on a.col1 = b.col1
- Когда пора выходить за рамки настройки 1 базы данных / 1 сервера? Насколько часто это нужно делать? Существуют ли какие-либо специальные стратегии для отслеживания того, какие таблицы находятся в какой базе данных?
Я объединю эти два, потому что они идут вместе. Вы почти всегда в порядке, если исходите из предположения, что одной базы данных и одного сервера достаточно до тех пор, пока ваши конструктивные / бизнес / технические ограничения не заставят вас использовать больше.
Итак, чтобы ответить на ваш второй вопрос в первую очередь, так как у вас, как правило, есть причина наличия отдельных баз данных, должно быть довольно очевидно, зная структуру вашей системы, где что-то находится.
Что касается того, когда и почему необходимо выйти за пределы одной базы данных. Обычно это сочетание бизнес-правил, политики и / или технических причин.
Например, там, где я работаю, у нас есть 16 баз данных, распределенных по 4 серверам. У нас есть MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB. Чтобы привести несколько примеров того, почему они разные:
- FinancialDB, конфиденциальная информация
- Образ БД, конкретные требования к хранению и восстановлению
- ReferenceDB, низкая транзакция, высокое чтение
- ReportingDB, с очень высоким чтением, должен быть восстановлен / реплицирован в различные другие среды в отличие от многих других данных
- StagingDB, ничего постоянного, просто усиленная база данных, над которой мы имеем больше контроля
- MainDB, взаимодействует со всеми другими БД, но требует дифференциального резервного копирования, так что ... мы разделили
- Таблицы HighVolumeTransaction (которые являются относительно переходными) к собственной БД, чтобы сохранить разумный размер резервной копии.
- Архив, множество одних и тех же данных из Main и Reporting, но с более длительными периодами хранения и более сложными запросами, копающимися глубоко в данных. Если бы это все еще сочеталось с Main / Reporting, это привело бы к падению нашей системы.
• Нужно ли коду приложения знать, что одна или несколько баз данных распределены по нескольким серверам? Если нет, то на каком уровне фильтруются запросы?
В широком смысле, они, вероятно, делают. Как минимум, им нужно знать, на какой сервер они указывают в строке подключения к базе данных. Обработка, отчетность, основная и т. Д.
Оттуда им нужен контекст базы данных для выполнения в. Как правило, это будет наиболее часто используемый для приложения, может быть, даже оригинальный из одной базы данных / один серверный день приложения. Вы МОЖЕТЕ заставить приложение явно переключать контекст базы данных при каждом вызове, но это очень затрудняет настройку базы данных без изменения приложения.
Обычный (или, по крайней мере, мой обычный) подход заключается в том, чтобы всегда получать доступ через одну или, может быть, две основные базы данных.
Затем создайте представления в других базах данных по мере необходимости в сочетании с взаимодействием с базой данных с помощью хранимых процедур.
Итак, для иллюстрации:
Допустим, вы хотите получить демографическую информацию о клиенте, данные о продажах и кредитный баланс, которые распределены по трем таблицам, изначально все в MainDB.
Итак, вы пишете звонок из вашего приложения:
Select c.ClientName, c.ClientAddress, s.totalSales,f.CreditBlance from
Clients c join Sales s on c.clientid = s.clientid inner join AccountReceivable f on
c.clientid=f.clientid where c.clientid = @clientid
Потрясающие. Однако теперь, когда мы меняем имя столбца или переименовываем / перемещаем таблицу, вы должны обновить код приложения. Таким образом, вместо этого мы делаем две вещи:
Создание клиентов, Продажи, Представления AccountReceivables (вы не использовали бы Select *, но я здесь демонстрирую)
Use MainDB
GO
Create view v_Clients as select * from Clients
Create view v_Sales as select * from Sales
Create view v_AccountReceivable as select * from AccountReceivable
Go
Затем мы также создали бы хранимую процедуру, spGetClientSalesAR
Create proc spGetClientSalesAR @clientID int
as
Select c.ClientName as ClientName,
c.ClientAddress as ClientAddress,
s.totalSales as TotalSales,
f.CreditBlance as CreditBalance
from
v_Clients c join v_Sales s
on c.clientid = s.clientid
inner join v_AccountReceivable f
on c.clientid=f.clientid
where c.clientid = @clientid
И пусть ваше приложение называет это.
Теперь, пока я не изменяю интерфейс этого хранимого процесса, я могу делать все, что мне нужно, с внутренней базой данных для увеличения или уменьшения масштаба.
В крайнем случае, я мог бы даже сделать мою старую MainDB просто кучей очищенных хранимых процедур и представлений, чтобы под созданными нами представлениями выглядело так:
Create view v_Clients as select * from ServerX.DatabaseY.dbo.Clients
Create view v_Sales as select * from ServerQ.DatabaseP.dbo.Sales
Create view v_AccountReceivable as select * from ServerJ.DatabaseK.dbo.AccountReceivable
И ваше приложение никогда не узнает разницы (при условии, что между прочим будут быстрые каналы и хорошо поставленные данные).
Очевидно, что это экстремально, и я бы соврал, если бы сказал, что все спланировано таким образом, но использование хранимых процедур / представлений, даже если вы делаете это во время рефакторинга, даст вам большую гибкость, поскольку ваше приложение вырастает из своей скромной базы данных / одного сервера. начало.