anningo 様、ご返信ありがとうございます。
拙い説明で、お手数ををおかけして申し訳ありません。
> 外部キーの削除、再作成が必要ならば、瞬時というわけにはいかないのでは？
> でも、リネームじゃない方法にしても外部キーの扱いに時間はかかりますよね
おっしゃるとおりだと思います･･･。
現在は、１度本テーブルからデータを全て削除し、順にBULK INSERTする、という方法を
取っており、データ登録中は、アプリケーションのサービスを停止しています。
せめて、データを登録すること自体を、事前に行っておけば、切替の時間が
短くなるのでは、と思い、上手くテーブルを複製しておいて切り替えるような方法が
ないものかどうか、と思い、問合わせをさせていただきました･･･。
“瞬時”などという紛らわしい表現を使って申し訳ありません。
> 外部キーはどうしても必要ですか？
> 夜間にそっくりデータ入れ替えできるということは
> 日中に更新をかけるようなテーブルではないですよね？（←AAA.dbo.TableA、AAA.dbo.TableB）
詳しい記載をしておらず、申し訳ありません。
日中は日中で、データメンテナンス用の画面からの入力によって、親となるデータベースに発生した
データのメンテナンス情報(差分)や、自分以外の子供となるデータベースで発生したメンテナンス情報を
親経由で随時受け付けています。
(自分自身にメンテナンスがあった場合も、親となるサーバへ情報を送っています)
この差分情報は、親となるデータベースを持つサーバで、連番をつけて管理しています。
それとは別に、親となる外部のデータベースのほうに大きな変更があった場合(主に夜間)に、
今回質問にあげさせていただいたような、全件のファイルが送られてくる形です。
(このとき、そのデータは、差分のどの連番のものまで反映されたものか、という情報を
受け取り、それ以前の連番の差分情報は、反映不要、と見なす形です)
> 外部キーの対象になっているテーブルに更新をかけるとき
> UPDATEクエリー実行の前に、プログラムで整合性チェックをかけていませんか？
> つまり、外部キーが役に立つケースは本当にあるのでしょうかという確認です。
上記の通り、
１．データメンテナンス用の画面、２．外部から届いた差分のメンテナンス情報、３．一括で届く情報、の
３つの種類の入力による更新方法が存在しますが、
１．については、ある程度のチェックは行っているものの、シビアなタイミングでのチェックはSQLServerに
頼っているのが現状です･･･。
２．については、画面での登録である程度チェックが行われている前提とし、プログラムによるチェックは
行っていません。
３．についても、前回記述しましたとおり、同制約がついたところから発信されたデータとして信頼し、
事前のチェックは行わずに取り込んでいます
子供となるデータベース発の変更が発生しなければ、削除してしまっても、と思うのですが、
こちらからもメンテナンス用の画面からのデータ変更が発生するため、削除してしまうのは不安な状況です。
以上で、ご確認いただいた内容に、回答できておりますでしょうか？
不足や不備等ございましたら、お手数ですが、ご指摘をお願いいたします。
