هل هناك مصدر قانوني يدعم "جميع البدائل"؟

Question

خلفية

ال "يجب أن يكون جميع بدائل PK" النهج غير موجود في نموذج كود العلائقي أو أي معيار SQL (ANSI، ISO أو غيرها).

يبدو أن الكتب القانونية تتهرب من هذه القيود أيضًا.

يستخدم نظام قاموس البيانات الخاص بشركة Oracle المفاتيح الطبيعية في بعض الجداول والمفاتيح البديلة في جداول أخرى.أذكر هذا لأن هؤلاء الأشخاص يجب أن يعرفوا شيئًا أو اثنين عن تصميم RDBMS.

PPDM (الرابطة المهنية لإدارة البيانات البترولية) توصي بنفس الكتب الأساسية التي توصي بها:

استخدم المفاتيح البديلة كمفاتيح أساسية عندما:

1. لا توجد مفاتيح طبيعية أو تجارية
2. المفاتيح الطبيعية أو المفاتيح التجارية سيئة (تتغير كثيرًا)
3. لا تكون قيمة المفتاح الطبيعي أو التجاري معروفة في وقت إدراج السجل
4. المفاتيح الطبيعية متعددة الأعمدة (عادةً عدة FK) تتجاوز ثلاثة أعمدة، مما يجعل الصلات مطولة للغاية.

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

أذكر PPDM لأن هؤلاء الأشخاص يجب أن يعرفوا شيئًا أو اثنين عن تصميم RDBMS أيضًا.

يبدو أن أصول نهج "جميع البدائل" تأتي من توصيات بعض أطر عمل ORM.

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

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

الأسئلة

- هل هناك أي مصدر قانوني يدعم منهج "جميع PK يجب أن يكون بديلاً"؟

- هل تم استبدال نموذج Codd العلائقي بنموذج علائقي أحدث؟

Answer 1

"جميع PKs بدائل" ليست استراتيجية سليمة للغاية على الإطلاق بالتأكيد ليس مصدرًا من المحتمل أن تجد له مصدرًا "موثوقًا"..

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

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

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

Answer 2

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

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

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

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

أنظر أيضا
http://en.wikipedia.org/wiki/Surrogate_key