sql sp1 المركب المفتاح الأساسي مقابل عمود "معرف" إضافية؟




database diagrams sql server (4)

لو كان لدينا جدول مثل هذا:

الكتب (التظاهر "ISBN" غير موجود)

  • مؤلف
  • عنوان
  • الإصدار
  • سنة النشر
  • السعر

يمكن للمرء أن يجادل بأن {Author، Title، Edition} يمكن أن يكون مفتاحًا مرشحًا / أساسيًا.

ما الذي يحدد ما إذا كان يجب أن يكون المرشح / المفتاح الأساسي {Author أو Title أو Edition} أو ما إذا كان يجب استخدام عمود المعرف ، مع {Author، Title، Edition} قيد فريد من الفهرس / المفتاح؟

هكذا هو

  • المؤلف (PK)
  • العنوان (PK)
  • الطبعة (PK)
  • سنة النشر
  • السعر

أفضل ، أو:

  • معرف (PK)
  • مؤلف
  • عنوان
  • الإصدار
  • سنة النشر
  • السعر

حيث {Author، Title، Edition} هو مؤشر / قيد فريد إضافي؟


Answer #1

لنفترض أن {Author,Title,Edition} يعرّف كتابًا بشكل فريد ، ثم يحمل ما يلي:

  1. إنه مفتاح (عظمى) - يميز بشكل فريد الصفوف (الصف).

  2. إنه غير قابل للاختزال - إزالة أي من الأعمدة لا يجعلها مفتاحًا بعد الآن.

  3. إنه مفتاح مرشح - المفتاح غير القابل للاختزال هو مفتاح المرشح.

الآن دعنا نفكر في المعرف (عدد صحيح)

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

من أجل جعل هذه الجداول والفهارس "الأخرى" أصغر يمكنني إضافة عمود عدد صحيح فريد إلى جدول Book لاستخدامه كمفتاح والذي سيشار إليه كمفتاح خارجي. قل شيئًا مثل:

alter table `Book` add `BookID` integer not null identity;

مع BookID يجري (يجب أن يكون) فريدة من نوعها أيضا ، الجدول Book يحتوي الآن على اثنين من مفاتيح الترشيح.

الآن يمكنني تحديد BookID كمفتاح أساسي.

alter table Book add constraint pk_Book primary key (BookID);

ومع ذلك ، يجب أن يظل {Author,Title,Edition} مفتاحًا (فريدًا) لمنع شيء كهذا:

BookID  Author      Title           Edition
----------------------------------------------- 
  1      C.J.Date  Database Design     1
  2      C.J.Date  Database Design     1

باختصار ، فإن إضافة BookID - واختياره على أنه الأساسي - لم يوقف {Author,Title,Edition} كونه مفتاح (مرشح). لا يزال يجب أن يكون القيد الفريد الخاص به وعادة ما يكون مؤشر مطابقة.

لاحظ أيضًا أنه من نقطة التصميم ، تم اتخاذ هذا القرار على "المستوى المادي". بشكل عام ، على المستوى المنطقي للتصميم ، لا يوجد هذا ID - لقد تم تقديمه أثناء النظر في أحجام الفهارس والأعمدة. لذلك تم اشتقاق المخطط المادي من المخطط المنطقي. اعتمادًا على حجم DB و RDBMS والأجهزة المستخدمة ، قد لا يكون لأي من هذا المنطق حجمًا تأثيرًا قابلاً للقياس - لذلك قد يكون استخدام {Author,Title,Edition} كـ PK تصميمًا جيدًا تمامًا - إلى أن يثبت بشكل مختلف.


Answer #2

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

لنفترض أنك أنشأت جدول كتبك مع المؤلف كجزء من المفتاح الأساسي.

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

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

أخيراً ، أسماء جدول قاعدة البيانات عادةً ما تكون مفردة (Book) ، بدلاً من الجمع (Books).


Answer #3

هناك العديد من المقالات المتعلقة بهذا. المشكلات المتعلقة بالمفتاح المركب في حالتك:

  1. من الصعب ربط الكتب بالكيانات الأخرى
  2. من الصعب تعديلها في الشبكة لأن معظم الشبكات لا تدعم مفاتيح مركبة (مثل شبكة kendo ، jqgrid)
  3. قد تخطئ في كتابة المؤلف ، العنوان ، الطبعة

سيكون من الجيد أيضًا تطبيع بياناتك وتخزين معرّف فقط للمؤلف مثل (dasblinkenlight) المقترح. السيناريو الأسوأ ، هو / هي ستغير اسمه / اسمها (على سبيل المثال تزوجت ، وهي تحب اسمها الجديد).


Answer #4

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





database-design