الجداول التي لا تحتوي على مفتاح أساسي

Question

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

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

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

ما رأيك؟هل يجب أن تحتوي الجداول على مفاتيح أساسية؟أم أنه من المقبول عدم وجود أي فهارس مجمعة إذا لم تكن هناك أعمدة معقولة للفهرسة بهذه الطريقة؟

Answer 1

عند التعامل مع الفهارس، عليك تحديد الغرض الذي سيتم استخدام الجدول الخاص بك من أجله.إذا كنت تقوم بشكل أساسي بإدراج 1000 صف في الثانية ولا تقوم بأي استعلام، فإن الفهرس المجمع يعد بمثابة نتيجة للأداء.إذا كنت تجري 1000 استعلام في الثانية، فإن عدم وجود فهرس سيؤدي إلى أداء سيء للغاية.أفضل ما يمكنك فعله عند محاولة ضبط الاستعلامات/الفهارس هو استخدام محلل خطة الاستعلام وملف تعريف SQL في SQL Server.سيُظهر لك هذا المكان الذي تواجه فيه عمليات فحص الجدول المكلفة أو أدوات حظر الأداء الأخرى.

أما بالنسبة لوسيطة GUID مقابل ID، فيمكنك العثور على أشخاص عبر الإنترنت يقسمون بكليهما.لقد تعلمت دائمًا كيفية استخدام المعرفات الفريدة العمومية (GUIDs) إلا إذا كان لدي سبب وجيه لعدم القيام بذلك.لدى Jeff منشور جيد يتحدث عن أسباب استخدام المعرفات الفريدة العمومية (GUIDs): https://blog.codinghorror.com/primary-keys-ids-versus-guids/.

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

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

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

وأيضًا، نظرًا لتوزيع الإدخالات بشكل عشوائي، تقل فرصة تقسيم الصفحات بشكل كبير.على الرغم من أن تقسيم الصفحة هنا وهناك ليس أمرًا سيئًا للغاية، إلا أن التأثيرات تتراكم بسرعة.باستخدام IDENTITY، يعد عامل تعبئة الصفحة عديم الفائدة كآلية ضبط ويمكن أيضًا ضبطه على 100% - لن يتم إدراج الصفوف مطلقًا في أي صفحة باستثناء الصفحة الأخيرة.باستخدام NewID()، يمكنك بالفعل الاستفادة من عامل التعبئة كأداة لتمكين الأداء.يمكنك تعيين عامل التعبئة إلى مستوى يقارب نمو الحجم المقدر بين عمليات إعادة بناء الفهرس، ثم جدولة عمليات إعادة البناء أثناء ساعات خارج أوقات الذروة باستخدام dbcc Rendex.يؤدي هذا بشكل فعال إلى تأخير نتائج أداء تقسيمات الصفحة حتى أوقات خارج أوقات الذروة.

إذا كنت حتى يفكر قد تحتاج إلى تمكين النسخ المتماثل للجدول المعني - ثم يمكنك أيضًا جعل PK معرفًا فريدًا ووضع علامة على حقل الدليل كـ ROWGUIDCOL.سيتطلب النسخ المتماثل حقل دليل ذو قيمة فريدة بهذه السمة، وسيضيف واحدًا في حالة عدم وجوده.إذا كان هناك حقل مناسب، فسيتم استخدام الحقل الموجود هناك فقط.

هناك فائدة كبيرة أخرى لاستخدام المعرفات الفريدة العمومية (GUIDs) لـ PKs وهي حقيقة أن القيمة مضمونة بالفعل فريدة - وليس فقط بين جميع القيم التي تم إنشاؤها بواسطة هذا الخادم، ولكن كافة القيم التي تم إنشاؤها بواسطة الجميع أجهزة الكمبيوتر - سواء كان خادم قاعدة البيانات، أو خادم الويب، أو خادم التطبيقات، أو جهاز العميل.تتمتع كل لغة حديثة تقريبًا بالقدرة على إنشاء دليل صالح الآن - في .NET يمكنك استخدام System.Guid.NewGuid.يعد هذا مفيدًا جدًا عند التعامل مع مجموعات البيانات الرئيسية والتفصيلية المخزنة مؤقتًا على وجه الخصوص.لا يتعين عليك استخدام أنظمة مفاتيح مؤقتة مجنونة فقط لربط سجلاتك معًا قبل الالتزام بها.ما عليك سوى إحضار دليل جديد صالح تمامًا من نظام التشغيل لقيمة المفتاح الدائم لكل سجل جديد في وقت إنشاء السجل.

http://forums.asp.net/t/264350.aspx

Answer 2

يخدم المفتاح الأساسي ثلاثة أغراض:

• يشير إلى أن العمود (الأعمدة) يجب أن يكون فريدًا
• يشير إلى أن الأعمدة (الأعمدة) يجب أن تكون غير فارغة
• قم بتوثيق القصد من أن هذا هو المعرف الفريد للصف

يمكن تحديد الأولين بعدة طرق، كما فعلت بالفعل.

السبب الثالث جيد:

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

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

Answer 3

فقط قفزت، لأن مات خدعني قليلاً.

عليك أن تفهم أنه على الرغم من وضع فهرس متفاوت المسافات على المفتاح الأساسي للجدول بشكل افتراضي، إلا أن المفهومين منفصلان ويجب النظر إليهما بشكل منفصل.يشير CIX إلى الطريقة التي يتم بها تخزين البيانات والإشارة إليها بواسطة NCIXs، في حين يوفر PK تفردًا لكل صف لتلبية المتطلبات المنطقية للجدول.

الجدول الذي لا يحتوي على CIX هو مجرد كومة.غالبًا ما يُنظر إلى الجدول الذي لا يحتوي على PK على أنه "ليس جدولًا".من الأفضل أن تفهم مفهومي PK وCIX بشكل منفصل حتى تتمكن من اتخاذ قرارات معقولة في تصميم قاعدة البيانات.

روب

Answer 4

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

Answer 5

لقد سمعت أيضًا دائمًا أن وجود int المتزايد تلقائيًا يعد مفيدًا للأداء حتى لو كنت لا تستخدمه بالفعل.

Answer 6

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

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

من الناحية الفنية، يجب أن يكون هذا هو المجال الذي يعتمد عليه كل حقل آخر في الصف بشكل كامل.(إذا لم يكن الأمر كذلك فقد تحتاج إلى التطبيع).

من الناحية العملية، قد تعني مشكلات الأداء أنك تقوم بدمج الجداول واستخدام حقل تزايدي، ولكن يبدو أنني أتذكر شيئًا عن كون التحسين المبكر أمرًا شريرًا ...

Answer 7

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