زيادة حجم الزيادة لتتناسب مع ميزة GUID

Question

لقد كنت أفكر في تنفيذ هذا النظام، ولكن لا يسعني إلا أن أشعر أن هناك مشكلة في مكان ما.إحدى نقاط استخدام GUID بدلاً من زيادة int هي أنه في المستقبل، إذا كنت تريد دمج قواعد البيانات معًا، فلن يكون لديك أي تعارضات حول المفتاح/المعرف الأساسي.ومع ذلك، فإن النهج الذي أتبعه هو تعيين حجم الزيادة على X حيث X هو عدد الخوادم التي سأمتلكها على الأرجح في المستقبل.بعد ذلك، في كل خادم، اجعل البذرة تزيد عن رقم البذرة الموجود على الخادم السابق.بهذه الطريقة، أثناء الدمج، لن يكون هناك أي تعارض مع المفتاح الأساسي.هل هذه طريقة آمنة وطبيعية أم أنني فقدت صوابي :)؟شكرًا

Answer 1

في النسخ المتماثل لـ SQL متعدد الماجستير، عادةً ما يكون لديك مفاتيح أساسية محددة على النحو التالي:

• المعرفات الفريدة العمومية (GUIDs).
• int مع زيادة الحجم > عدد عمليات التثبيت
• int مع إزاحة ثابتة

الجانب السلبي للمعرفات الفريدة العمومية (GUIDs) هو أنه قد يكون من الصعب قراءتها وتشغل مساحة أكبر قليلاً.ومع ذلك، فهو يسمح لك بالتوسع إلى ن الحالات.

الأعداد الصحيحة أسهل قليلاً في التعامل معها.لديهم أيضًا ميزة القدرة على معرفة الخادم الذي أنشأ السجل بسهولة.الجانب السلبي هو أنه يجب عليك إما التنبؤ بالحد الأقصى لعدد قواعد البيانات التي يمكن دمجها، أو تخمين الحد الأقصى لعدد الصفوف التي يمكن لمثيل واحد إدراجها.

مثال على الإزاحة الثابتة هو:يبدأ الموقع "أ" من 0، ويبدأ الموقع "ب" من 1,000,000 ويبدأ الموقع "ج" من 2,000,000.يعمل هذا المخطط بشكل جيد حتى يقوم موقع واحد بإدراج مليون صف.قد يعمل هذا المخطط بشكل جيد مع السيارات لدى وكلاء السيارات، حيث من غير المحتمل أن يبيع أي تاجر أكثر من مليون سيارة، وقد يكون لديك مئات الوكلاء طوال عمر التطبيق.

Answer 2

ما يخيفني هنا هو استخدامك ل"على الارجح". كنت على افتراض حول مستقبل هنا، وعادة هذا ليس أمرا جيدا للقيام بأشياء من هذا القبيل. لماذا لا تستخدم GUID؟

وماذا لو قمت بإضافة خادم إضافي واحد على ما أعتقد أنك تريد ذلك؟ كنت أرى الأمور تزداد تعقيدا حقا حقا بسرعة.