좋아, 그것을 분해하자 :
- 여러 데이터베이스의 두 테이블간에 조인이 어떻게 구성됩니까? (여기 코드 예제가 도움이 될 것입니다).
이것은 매우 간단합니다. SQL 개체에는 1-4 개의 부분 명명 규칙이 있습니다.
서버 이름. 데이터베이스 이름. 스키마 이름. 테이블 이름
모든 테이블이 동일한 데이터베이스에서 동일한 소유자 / 스키마로 동일한 서버에있는 경우 처음 세 부분을 무시하고 가장 익숙한 것을 사용할 수 있습니다.
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 서버 설정을 넘어서는 시점은 언제입니까? 이렇게하는 것이 얼마나 흔한 일입니까? 어떤 데이터베이스에 어떤 테이블이 있는지 추적하기위한 특별한 전략이 있습니까?
이 두 가지를 함께 사용할 것입니다. 설계 / 비즈니스 / 기술적 제약으로 인해 더 많은 데이터베이스를 사용할 때까지 하나의 데이터베이스로 하나의 서버로 충분하다는 가정으로 시작하는 것이 좋습니다.
따라서 두 번째 질문에 먼저 대답하려면 일반적으로 별도의 데이터베이스가 있어야하는 이유가 있기 때문에 시스템의 디자인을 알고있는 것이 분명합니다.
언제 / 왜 단일 데이터베이스 이상으로 이동해야하는지에 대해. 일반적으로 비즈니스 규칙, 정치 및 / 또는 기술적 이유가 혼합되어 있습니다.
예를 들어, 내가 일하는 곳에서는 4 대의 서버에 16 개의 데이터베이스가 분산되어 있습니다. 우리는 MainDB, ImageDB, referencetableDB, HighvolumeTransactionDB, ReportingDB, StagingDB, ProcessingDB, ArchiveDB, FinancialDB를 가지고 있습니다. 왜 다른지 몇 가지 예를 들자면 :
- FinancialDB, 민감한 정보
- 이미지 DB, 특정 다른 스토리지 및 복구 요구 사항
- ReferenceDB, 낮은 트랜잭션, 높은 읽기
- 읽기 데이터가 많은 ReportingDB는 다른 많은 데이터와 달리 다양한 다른 환경으로 복원 / 복제해야합니다.
- StagingDB, 영구적이지 않은, 우리가 더 잘 제어 할 수있는 강화 된 tempdb
- MainDB는 다른 모든 DB와 인터페이스하지만 차등 백업이 필요하므로 ...
- 백업을 적당한 크기로 유지하기 위해 HighVolumeTransaction 테이블 (상대적으로 일시적인)을 자체 DB에 저장합니다.
- Archive, 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
대박. 그러나 이제 columname을 변경하거나 테이블 이름을 바꾸거나 테이블을 이동할 때마다 앱 코드를 업데이트해야합니다. 대신
클라이언트, 판매, 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
그리고 앱은 차이를 알지 못할 것입니다 (빠른 파이프와 잘 준비된 데이터를 가정 할 때).
분명히 모든 것이 이런 식으로 계획되었다고 말하면 극단적이며 거짓말을 할 것입니다. 그러나 리팩토링하는 동안 저장 프로 시저 / 뷰를 사용하더라도 응용 프로그램이 겸손한 하나의 데이터베이스 / 하나의 서버에서 성장함에 따라 많은 유연성이 허용됩니다 처음.