لماذا تحديد السمات الأساسية / الخارجية الرئيسية في أسماء الأعمدة

Question

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

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

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

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

select t1.col_a, t1.col_b, t2.col_z
from t1 inner join t2 on t1.id_foo = t2.id_foo

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

tx inner join ty on tx.id_bar = ty.id_bar

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

ما المشكلة يتم حلها هنا؟ (أعرف أن هذا هو دعوة للمناقشة، وتتردد في القيام بذلك. ولكن في الوقت نفسه، I <م> صباحا تبحث عن إجابة، في أنني قد يكون شيء مفقود حقا).

Answer 1

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

SELECT * FROM foo JOIN bar USING (foo_id);

والكلمة باستخدام تفترض أن عمود موجود بنفس الاسم في كلا الجدولين، وأنك تريد متساو-انضمام. من الجميل أن يكون هذا المتاحة والاختزال لأكثر مطول:

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

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

CREATE TABLE Employees (
  emp_id INT PRIMARY KEY,
  manager_id INT REFERENCES Employees(emp_id)
);

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

CREATE TABLE Bugs (
  ...
  reported_by INT REFERENCES Accounts(account_id),
  assigned_to INT REFERENCES Accounts(account_id),
  ...
);

وأنا لا أحب أن تشمل اسم الجدول في اسم العمود. وأود أيضا أن نتجنب واجبا "المعرف" كاسم عمود المفتاح الأساسي في كل طاولة.

Answer 2

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

Answer 3

ولقد تبنى معظم الأفكار المقترحة هنا على مدى السنوات ال 20 العش لقد تم تطوير مع قواعد البيانات SQL، وأنا أشعر بالحرج أن أقول. تسليم معظم منهم عدد قليل أو أي من الفوائد المتوقعة وكانت بعد فوات الأوان، ألم في الرقبة.

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

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

وتجاهل المفاتيح الأساسية المركبة، وأنا لا أرى لماذا شيء بسيط مثل "المعرف" لن يكون كافيا للحصول على مفتاح أساسي، و "_ID" لمفاتيح الأجنبية.

والانضمام لذا نموذجي حالة يصبح customer.id = order.customer_id.

وأين توجد جمعية أكثر من واحد بين جدولين، ويهمني أن يميل إلى استخدام رابطة بدلا من اسم الجدول، لذلك ربما "PARENT_ID" و "child_id" بدلا من "parent_person_id" الخ

Answer 4

وأنا فقط استخدام TABLENAME مع لاحقة رقم للمفتاح الأساسي، على سبيل المثال الرقم التعريفي للعميل، والأجنبية مفاتيح إشارتها إلى ذلك من جداول أخرى من شأنه أيضا أن يسمى الرقم التعريفي للعميل. عند الرجوع في تطبيق يصبح من الواضح الجدول من خصائص الكائن، على سبيل المثال Customer.TelephoneNumber، Customer.CustomerId، وما إلى ذلك.

Answer 5

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

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

هل لديك فكرة جيدة!

Answer 6

وأنا أتفق معك - أنا اتخاذ نهج مختلف بأنني ينظر الموصى بها في العديد من بيئات الشركات:

والأعمدة الاسم في شكل <م> TableNameFieldName ، حتى إذا كان لدي جدول العملاء وكان اسم المستخدم واحدا من المجالات بلدي، والميدان سوف يطلق CustomerUserName. وهذا يعني أنه إذا كان جدول آخر يسمى الفاتورة، وكان اسم المستخدم العميل مفتاح خارجي، وأود أن نسميها InvoiceCustomerUserName، وعندما المشار إليها، وأود أن نسميها Invoice.CustomerUserName، الذي يحكي لي على الفور أي جدول انها في.

وأيضا، وهذا التسمية يساعدك على تتبع جداول الأعمدة تأتي من عندما كنت joiining.

وأنا فقط استخدام FK_ وPK_ في أسماء الفعلية من المفاتيح الخارجية والأولية في نظم إدارة قواعد البيانات.