このシナリオでは、データベースを 2 つに分割する必要がありますか?
シナリオ
顧客がテーブルで注文を作成、編集、保存している間Orderに、Web サイトの所有者はストアド プロシージャを呼び出して、テーブルのテーブル プロパティを変更しEmailます。
アップデート
Order テーブルと Email テーブルとの唯一の関係は、 userId (Email テーブルの FK) です。したがって、顧客が注文しているときに、同時にnull許容の「CcAddressId」列をEmailテーブルに追加すると、どのような影響がありますか。この注文が成功すると問題が発生しますか?
質問:
短い答えは、他の人が上で提起した他の問題は言うまでもなく、外部キーによって強制された参照整合性が失われるため、データベースを2つに分割しないことです。Orders テーブルにデータを挿入するときに、SQL Server が EMails テーブルに対して何らかの種類のロックを発行するかどうかを確認する必要があります。これを出発点として使用して、自分で実験して調べることができます。
http://aboutsqlserver.com/2012/04/05/locking-in-microsoft-sql-server-part-13-schema-locks/
テーブルを変更すると、他の種類のロックと互換性のないスキーマ変更ロック (SCH-M) を発行しようとします。したがって、変更されているテーブルに対して何らかのアクティビティが行われている場合 (これは、外部キー制約が検証されているためだと思います)、スキーマ変更ステートメントは長時間ブロックされます。
これが、データベースの負荷が高くないときにスキーマ変更ステートメントを実行する方がよい理由です。