sql - تعريف - primary key and foreign key شرح




المفتاح الأساسي/الخارجي لمفتاح التسمية (9)

في مجموعة المطورين لدينا لدينا مناقشة مستعرة فيما يتعلق باتفاقية تسمية المفاتيح الأساسية والخارجية. هناك في الأساس مدرستان فكريتان في مجموعتنا:

1:

Primary Table (Employee)   
Primary Key is called ID

Foreign table (Event)  
Foreign key is called EmployeeID

أو

2:

Primary Table (Employee)  
Primary Key is called EmployeeID

Foreign table (Event)  
Foreign key is called EmployeeID

أنا أفضل عدم تكرار اسم الجدول في أي من الأعمدة (لذلك أنا أفضل الخيار 1 أعلاه). من الناحية المفاهيمية ، تتفق مع الكثير من الممارسات الموصى بها في اللغات الأخرى ، حيث لا تستخدم اسم الكائن في أسماء الخصائص الخاصة به. أعتقد أن تسمية المفتاح الخارجي EmployeeID (أو قد يكون Employee_ID أفضل) يخبر القارئ أنه عمود ID من جدول Employee .

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

أيضًا ، أعتقد أنه من المكرر أن يكون اسم الجدول في اسم العمود ، لأنه إذا كنت تفكر في الجدول ككيان وعمود كممتلكات أو خاصية لهذا الكيان ، فستفكر فيه كصفة المعرّف Employee ، لا سمة EmployeeID الموظف. أنا لا أذهب أسأل زميلي في العمل ما هو PersonAge أو PersonGender . أسأله ما هو عصره.

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


"أين في" الموظف INNER JOIN order ON order.employee_id = employee.id "هل هناك حاجة إلى تأهيل إضافي؟".

ليست هناك حاجة لمزيد من التأهيل لأن المؤهل الذي تحدثت عنه موجود بالفعل.

"السبب الذي يشير إلى أن مستخدم الأعمال يشير إلى معرّف الطلب أو معرّف الموظف هو توفير السياق ، ولكن على مستوى dabase يكون لديك بالفعل سياق لأنك تقوم بالتحديث إلى الجدول".

صلي ، أخبرني ، إذا كان العمود يدعى "المعرف" ، فكيف يتم ذلك "إعادة التنظيم [كذا] إلى الجدول" تمامًا ، ما لم يكن ذلك من خلال تأهيل هذا المرجع لعمود المعرّف بالضبط بالطريقة التي تحدثت عنها؟


أعتقد أن ذلك يعتمد على طريقة وضعك للتطبيق. إذا كنت تستخدم ORM أو صممت الجداول لتمثيل الكائنات ، فقد يكون الخيار 1 من أجلك.

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


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


أوافق على أن هناك القليل للاختيار بينهما. بالنسبة لي ، هناك شيء أكثر أهمية حول المعيار هو الجزء "القياسي".

إذا بدأ الناس "القيام بأشياءهم الخاصة" يجب أن يعلقوا من قبل نيذرهم. IMHO :)


إذا كنت تبحث في رمز التطبيق ، وليس فقط طلبات البحث في قاعدة البيانات ، فبعض الأمور تبدو واضحة بالنسبة لي:

  1. عادةً ما تعيّن تعريفات الجدول مباشرةً فئة تصف كائنًا واحدًا ، لذا يجب أن تكون مفردة. لوصف مجموعة من الكائنات ، عادة ما أرفق "Array" أو "List" أو "Collection" بالاسم المفرد ، لأنه أكثر وضوحًا من استخدام صيغ الجمع ليس فقط أنه مجموعة ، ولكن ما هو نوع المجموعة أنه. في هذا العرض ، أرى اسم الجدول ليس اسم المجموعة ، ولكن اسم نوع الكائن الذي هو مجموعة منه. قد يفتقد DBA الذي لا يكتب رمز التطبيق هذه النقطة.

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


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


لا يهم حقا. لم أواجه مطلقًا نظامًا حيث يوجد فرق حقيقي بين الخيار 1 والخيار 2.

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

اختر واحدًا وأطلب منهم التركيز على المشكلات التي تؤثر فعليًا على شفرتك.

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


لطالما استخدمت userId كـ PK في جدول واحد و userId على طاولة أخرى ك FK. 'm التفكير بجدية في استخدام userIdPK و userIdFK كأسماء للتعرف على واحد من الآخر. سيساعدني ذلك على تحديد PK و FK بسرعة عند النظر إلى الجداول ويبدو أنه سيزيل الشفرة عند استخدام PHP / SQL للوصول إلى البيانات مما يسهل فهمها. خاصة عندما ينظر شخص آخر إلى شفرتي.


هل فكرت في التالي؟

Primary Table (Employee)   
Primary Key is PK_Employee

Foreign table (Event)  
Foreign key is called FK_Employee




naming-conventions