わかりました、それを分解しましょう：
- 複数のデータベース上の2つのテーブル間で結合はどのように構築されますか？（ここのコード例が役立ちます）。
これは非常に簡単です。SQLオブジェクトには、1〜4部の命名規則があります。
サーバー名。データベース名。スキーマ名。テーブル名
すべてのテーブルが同じ所有者/スキーマで同じデータベースの同じサーバーにある場合、最初の3つの部分を無視して、最もよく使用するものを使用できます。
Select a.*,b.* from
tableA a inner join
tableB b on a.col1=b.col1
テーブルの1つが別のデータベースにあり、両方がデータベースのデフォルトスキーマを使用している場合、データベースを2番目のテーブルに追加するだけです。
Select a.*,b.* from
tableA a inner join
databaseC..tableB b on a.col1 = b.col1
クエリを実行しているデータベースのいずれとも異なる3番目のデータベースにいる場合は、両方のデータベース名を明示的に使用します。
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サーバーのセットアップを超える時期はいつですか？これを行う必要があるのはどれくらい一般的ですか？どのテーブルがどのデータベースにあるかを追跡するための特別な戦略はありますか？
これら2つが一緒になるので、これら2つを組み合わせます。ほとんどの場合、設計/ビジネス/技術的な制約によりさらに多くの使用が必要になるまで、1つのデータベースが1つのサーバーで十分であるという前提から始めても大抵は問題ありません。
したがって、最初に2番目の質問に答えるには、通常、個別のデータベースを使用する理由があるため、システムの設計がどこにあるかを知っていれば、それはかなり明白なはずです。
いつ/なぜ、単一のデータベースを越えて移動する必要があるかについて。通常、ビジネスルール、政治、および/または技術的な理由が混在しています。
たとえば、私が働いている場所では、4つのサーバーに16個のデータベースが分散しています。MainDB、ImageDB、referencetableDB、HighvolumeTransactionDB、ReportingDB、StagingDB、ProcessingDB、ArchiveDB、FinancialDBがあります。それらが異なる理由の例を挙げます：
- FinancialDB、機密情報
- イメージDB、特定の異なるストレージおよびリカバリ要件
- ReferenceDB、低トランザクション、高読み取り
- 非常に高い読み取りのReportingDBは、他の多くのデータとは異なり、さまざまな他の環境に復元/複製する必要があります
- StagingDB、永続的なものではなく、強化されたtempdb
- MainDB、他のすべてのDBとインターフェイスしますが、差分バックアップが必要なため、...
- HighVolumeTransactionテーブル（比較的一時的）、バックアップを適切なサイズに保つために、独自のDBに。
- アーカイブ、メインとレポーティングからの同じデータがたくさんありますが、保持期間が長く、データを掘り下げるクエリのヒットがより困難です。これがMain / Reportingとまだ組み合わされていると、システムが動かなくなります。
• アプリケーションコードは、1つ以上のデータベースが複数のサーバーに分散していることを知る必要がありますか？そうでない場合、要求はどのレベルでフィルタリングされますか？
広い意味で、おそらくそうでしょう。少なくとも、データベース接続文字列でどのサーバーを指しているのかを知る必要があります。処理、レポート、メインなど
そこから実行するには、データベースコンテキストが必要です。通常、これはアプリケーションで最も使用されるものであり、アプリケーションの1データベース/ 1サーバー日からのオリジナルのものである可能性があります。アプリケーションは、呼び出しごとにデータベースコンテキストを明示的に切り替えることができますが、アプリケーションを変更せずにデータベースを調整することは非常に困難です。
通常の（または少なくとも、私の通常の）アプローチは、常に1つまたは2つのメインデータベースを介してアクセスすることです。
次に、必要に応じて、ストアドプロシージャを介したデータベースとのインターフェイスと組み合わせて、他のデータベースにビューを作成します。
だから説明するために：
クライアントの人口統計情報、売上データ、およびクレジット残高を取得したいとしましょう。これらはすべてMainDBの3つのテーブルに分散しています。
したがって、アプリから呼び出しを作成します。
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を変更したり、テーブルの名前を変更したり移動したりするたびに、アプリコードを更新する必要があります。そのため、代わりに2つのことを行い
ます。クライアントビュー、セールスビュー、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
そして、あなたのアプリはその違いを決して知ることはありません（特に高速パイプと適切にステージングされたデータを想定しています）。
明らかにそれは極端であり、すべてがこのように計画されていると言ったら嘘をつきますが、リファクタリング中にそれを行ってもストアドプロシージャ/ビューを使用すると、アプリが謙虚な1つのデータベース/ 1つのサーバーから成長するときに、多くの柔軟性が得られます始まり。