GUIDの利点に合わせて増分サイズを増やす
-
05-07-2019 - |
質問
このシステムを実装することを考えてきましたが、どこかにキャッチがあると感じずにはいられません。増分intを介してGUIDを使用するポイントの1つは、将来、データベースを一緒にマージする場合、プライマリキー/識別子で競合が発生しないことです。ただし、私のアプローチは、増分サイズをXに設定することです。ここで、Xは、おそらく今後使用するサーバーの数です。次に、各サーバーで、シードを前のサーバーのシード番号よりも大きくします。そうすれば、マージ中に主キーと衝突することはありません。これは安全な通常の方法ですか? ありがとう
解決
マルチマスターSQLレプリケーションでは、通常、次のように定義された主キーがあります。
- GUID
- intの増分サイズ>インストール数
- 固定オフセットの整数
GUIDの欠点は、読み取りが難しくなり、スペースがわずかに増えることです。ただし、 n 個のインスタンスに拡張できます。
整数は扱いが少し簡単です。また、どのサーバーがレコードを作成したかを簡単に確認できるという利点もあります。欠点は、マージできるデータベースの最大数を予測するか、単一のインスタンスが挿入する可能性のある最大行数を推測する必要があることです。
固定オフセットの例:サイトAは0から始まり、サイトBは1,000,000から始まり、サイトCは2,000,000から始まります。このスキームは、1つのサイトが100万行を挿入するまで正常に機能します。このスキームは、1つのディーラーが1,000,000台を超える自動車を販売することはまずないため、自動車のディーラーの車に適しています。
他のヒント
ここで私を怖がらせているのは、「最も可能性が高い」の使用です。ここでは未来を想定しているので、通常、このようなことを行うのは良いことではありません。 GUIDを使用しないのはなぜですか?
あなたが持っていると思っていたものの上に1つの余分なサーバーを追加するとどうなりますか?私は物事が本当にすぐに本当に複雑になるのを見ました