الانتقال من ints إلى GUIDs كمفاتيح أساسية

https://stackoverflow.com/questions/138177

02-07-2019
|

سؤال

أستخدم عدة جداول مرجعية تحتوي على مفاتيح أساسية ذات عدد صحيح.الآن أريد تغيير ints إلى GUIDs مع ترك جميع المراجع سليمة.ما هي أسهل طريقة للقيام بذلك؟

شكرًا لك!

إضافة

أنا أفهم العملية بشكل عام، لذا أحتاج إلى نصائح أكثر تفصيلاً، على سبيل المثال، كيفية ملء عمود GUID الجديد.استخدام القيمة الافتراضية newid() هو الصحيح، ولكن ماذا عن الصفوف الموجودة بالفعل؟

المحلول

قم بإنشاء عمود جديد لقيمة GUID في الجدول الرئيسي.استخدم نوع بيانات idqueidentifier ، اجعله لا خيرًا مع افتراضي NewID () بحيث يتم ملء جميع الصفوف الموجودة.
قم بإنشاء أعمدة فريدة من نوعها في الجداول الفرعية.
قم بتشغيل بيانات التحديث لبناء علاقات الجماعة باستخدام علاقات int الموجودة للإشارة إلى الكيانات.
قم بإسقاط أعمدة int الأصلية.

بالإضافة إلى ذلك، اترك بعض المساحة في صفحات البيانات/الفهرس الخاصة بك (حدد عامل التعبئة < 100) لأن الأدلة ليست متسلسلة مثل أعمدة هوية int.وهذا يعني أن الإدخالات يمكن أن تكون في أي مكان في نطاق البيانات وسوف تتسبب في انقسام الصفحات إذا كانت صفحاتك ممتلئة بنسبة 100%.

نصائح أخرى

أولاً:عزيزي الله لماذا؟!؟!؟

ثانيًا، سيتعين عليك إضافة عمود GUID إلى جميع جداولك أولاً، ثم ملؤها بناءً على قيمة int.بمجرد الانتهاء من ذلك، يمكنك تعيين المعرفات الفريدة العمومية (GUIDs) على المفاتيح الأساسية/الخارجية ثم إسقاط أعمدة int.

لتحديث القيمة ستفعل شيئًا مثل

قم بتعيين المعرفات الفريدة العمومية (GUIDs) الجديدة في جدول المفتاح الأساسي
تشغيل هذا:

UPDATE foreignTable f
SET f.guidCol = p.guidCol
FROM primaryTable p
WHERE p.intCol = f.intCol

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

لقد كان لدي امتياز مشكوك فيه للقيام بذلك من قبل وكان ما كان علي فعله هو تصدير قاعدة البيانات اللعينة بأكملها إلى XML.بعد ذلك، كان لدي تطبيق Java يستخدم وظيفة java.util.Random's nextLong() لاستبدال المفتاح الأساسي بمفاتيح الدليل الجديدة الخاصة بهم.بعد ذلك قمت باستيراد كل شيء مرة أخرى إلى قاعدة البيانات.

بالطبع، في المرة الأولى التي حاولت فيها استيراد ملفات XML مرة أخرى، نسيت إيقاف تشغيل ميزة الرقم التلقائي لحقل المفتاح الأساسي، لذا تعلم من أخطائي.أنا متأكد من أن هناك طرق أفضل للقيام بذلك، ولكن هذه كانت طريقة سريعة وقذرة للقيام بذلك ...وقد نجحت.في حال كنت تتساءل، كان المشروع هو جعل نطاق التطبيق.

نعم أنا مع جلين...في الواقع كنت مترددا في نشر نفس الشيء قبل أن ينشره....

لماذا لا تريد زيادة تلقائية في المفتاح الأساسي بشكل منفصل عن GUID الخاص بك؟إنه أكثر مرونة، ويمكنك فقط فهرسة عمود GUID حتى يكون لديك أداء جيد في استعلاماتك...

أما بالنسبة للمرونة، فأنا أحب الاحتفاظ بالمعرف الخاص بي على شكل increment ints لأنه بعد ذلك يمكن أن يتغير العنصر الآخر الذي يبدو فريدًا ويستحق المفتاح الأساسي.

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

أعتقد أنه يجب عليك القيام بذلك يدويًا.أو يمكنك كتابة بعض المرافق لذلك.السيناريو يجب أن يكون:

قم بتكرار أعمدة PK/FK "int" مع أعمدة "guid" جديدة.
ينشئ قيمًا جديدة لأعمدة PK "المرشدة".
قم بتحديث القيم في أعمدة FK "guid" بقيم محددة (يمكنك العثور على السجلات عبر "int" PK).
قم بإزالة المراجع (العلاقات) مع أعمدة PK/FK "int".
قم بإنشاء مراجع مماثلة (علاقات) باستخدام أعمدة PK/FK "المرشدة".
قم بإزالة أعمدة PK/FK "int".

من المضحك أنني أعتقد أنني بحاجة إلى القيام بالعكس تمامًا بسبب مشكلة أخرى ...

كيف يمكن استخدام SQLBulkCopy على جدول باستخدام مفتاح GUID الأساسي ومعرف الأخبار الافتراضي ()؟

إنه اختيار جيد جدًا.لقد قمت بالتبديل من الطلب الطويل إلى UUID لأحد تطبيقاتي ولست أندم على ذلك.إذا كنت تستخدم MS SQL Server، فسيتم تضمينه في المعيار (أستخدم postgresql وهو مضمن فقط في الإصدار القياسي من 8.3 وما بعده).

مثل ما ذكره جلين سلافين, ، يمكنك إعادة إنشاء UUIDs من المفاتيح الموجودة في سجلاتك الحالية.كن مدركًا أنها لن تكون فريدة من نوعها، ولكن بهذه الطريقة يكون من السهل الحفاظ على العلاقات سليمة.ستكون السجلات الجديدة التي تقوم بإنشائها بعد النقل فريدة من نوعها.

لا تفعل ذلك!لقد بدأنا باستخدام المعرفات الفريدة العمومية (GUIDs)، والآن انتهينا تقريبًا من الانتقال إلى INTs كـ PKs؛نحن نحتفظ بالمعرف الفريد العمومي (GUID) لأغراض التسجيل (وبالنسبة لبعض جداول "السلامة العلائقية القابلة للتفاوض"؛))، ولكن الزيادة في سرعة استخدام ints كانت هائلة.

لقد أصبح هذا واضحًا فقط عندما تجاوز عدد صفوف الجدول الملايين، انتبه.

كانت أكبر حماقتنا على الإطلاق هي استخدام NEWID() باعتباره PK لجدول السجل (المتسلسل) الخاص بنا - كان هناك الكثير من الصدمة عندما أدركنا خطأنا.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow