long vs Guide for the Id (الكيان)، ما هي الإيجابيات والسلبيات

Question

أقوم بإنشاء تطبيق ويب على asp.net mvc وأختار بين نوع البيانات الطويلة ونوع البيانات الإرشادية للكيانات الخاصة بي، لكنني لا أعرف أيهما أفضل.يقول البعض أن فترة طويلة أسرع بكثير.قد يكون للدليل أيضًا بعض المزايا.أي شخص يعرف ؟

Answer 1

عندما تكون المعرفات الفريدة العمومية (GUIDs) غير مناسبة

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

ضع في اعتبارك أيضًا ما إذا كان من المناسب استخدام "طويل" أم لا.وهذا عدد كبير للغاية.أنت بحاجة إليها فقط إذا كنت تعتقد أنه قد يكون لديك أكثر من 2 مليار إدخال في جدولك في وقت ما.ومن النادر أن أستخدمها.

يمكن أيضًا أن تكون المعرفات الفريدة العمومية (GUIDs) صعبة الاستخدام وتصحيح الأخطاء.القول، "هناك مشكلة في سجل العميل 10034، فرانك، اذهب للتحقق من ذلك" أسهل كثيرًا من قول "هناك مشكلة في {2f1e4fc0-81fd-11da-9156-00036a0f876a}..." للكتابة في الاستعلامات عندما تحتاج إلى ذلك.

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

عندما تكون المعرفات الفريدة العمومية (GUIDs) مناسبة

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

تسمح لك المعرفات الفريدة العمومية (GUIDs) أيضًا بالقدرة على ربط الكيانات دون الاحتفاظ بها في قاعدة البيانات، في سيناريوهات ORM معينة.Linq to SQL (وأعتقد أن EF) لا تواجه هذه المشكلة، على الرغم من وجود أوقات قد تضطر فيها إلى إرسال تغييراتك إلى قاعدة البيانات للحصول على المفتاح.

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

نصيحتي

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

Answer 2

بحجم:طويل هو 8 بايت GUID هو 16 بايت

guid لديه بالتااكيد احتمال كبير لن يكون فريدا والأفضل استخدام لتحديد السجلات الفردية في قاعدة بيانات (ق).

قد يمثل فترة طويلة (الهوية في DB) سجل فريد في طاولة ولكن قد يكون لديك سجلات تمثلها نفس معرف (الهوية)، في طاولة مختلفة أو أكثر كما يلي:

TableA: PersonID int, name varchar(50)
TableB: ProductID int, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name =''

كلاهما يمكن إرجاع القيمة نفسها، ولكن في حالة GUID:

TableA: PersonID uniqueidentifier, name varchar(50)
TableB: ProductID uniqueidentifier, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name ='

نادرا ما يكون لديك نفس القيمة حيث عاد المعرف من طاولتين

إلقاء نظرة هنا

• SQL Server - GUID VS. طويل
• GUIDS كمفاتيح أساسية و / أو مفتاح التجميع

Answer 3

اجعل GUIDs أسهل بكثير لإنشاء كيان "جديد" في واجهة برمجة تطبيقاتك لأنك تقوم ببساطة بتعيينها قيمة guid.newguid (). لا يوجد اعتماد على المفاتيح التلقائية من قاعدة بيانات، بحيث يكون هذا العدوء أفضل نموذج المجال من آلية الثبات الأساسية.

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

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