تسمية معرف الأعمدة في جداول قاعدة البيانات

Question

كنت أتساءل الشعوب آراء حول تسمية معرف الأعمدة في جداول قاعدة البيانات.

إذا كان لدي جدول يسمى الفواتير مع مفتاح أساسي من هوية عمود أسميه هذا العمود InvoiceID حتى لا يتعارض مع الجداول الأخرى و من الواضح ما هو عليه.

أين أنا workind الحالي قد دعا جميع معرف أعمدة الهوية.

لذلك فإنها تفعل ما يلي:

Select  
    i.ID 
,   il.ID 
From
    Invoices i
    Left Join InvoiceLines il
        on i.ID = il.InvoiceID

الآن أرى بعض المشاكل هنا:
1.سوف تحتاج إلى اسم مستعار الأعمدة على تحديد
2.ID = InvoiceID لا يصلح في دماغي
3.إذا لم مستعار الجداول المشار إليها InvoiceID هو واضح في الجدول ما هو ؟

ما هي الشعوب الأخرى الأفكار حول الموضوع ؟

Answer 1

وID هو المضادة للنموذج SQL. انظر HTTP: // www.amazon.com/s/ref=nb_sb_ss_i_1_5؟url=search-alias٪3Dstripbooks&field-keywords=sql+antipatterns&sprefix=sql+a

إذا كان لديك العديد من الجداول مع ID باسم معرف كنت ترغب بجعل التقارير أن أكثر صعوبة. أنه يخفي المعنى ويجعل استعلامات معقدة من الصعب قراءة وكذلك يتطلب منك استخدام الأسماء المستعارة للتمييز على التقرير نفسه.

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

إذا كنت ترغب في استخدام بناء الجملة يستعمل أن بعض DBS تسمح، لا يمكنك إذا كنت تستخدم ID.

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

وهكذا كان لديك الآن

select t1.field1, t2.field2, t3.field3
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t1.id = t3.table2id

وعندما كنت تعني

select t1.field1, t2.field2, t3.field3 
from table1 t1 
join table2 t2 on t1.id = t2.table1id
join table3 t3 on t2.id = t3.table2id

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

Answer 2

وأنا دائما يفضل ID إلى TABLENAME ID + للعمود الهوية وثم TABLENAME + ID لمفتاح خارجي. بهذه الطريقة جميع الجداول لها نفس الاسم للحقل معرف وليس هناك وصفا لزوم لها. هذا يبدو أكثر بساطة بالنسبة لي لكافة الجداول لها نفس المفتاح الأساسي اسم الحقل.

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

Answer 3

وثرس] كانت معركة الطالب الذي يذاكر كثيرا عن هذا الشيء في الشركة التي أعمل بها في الآونة الأخيرة. جعلت ظهور LINQ لزوم <م> TABLENAME + ID نمط أكثر الواضح سخيفة في عيني. أعتقد أن الناس معقولة سيقول أنه إذا كنت ناحية كتابة SQL الخاصة بك في مثل هذه الطريقة كما أن لديك لتحديد أسماء الجدول للتمييز <م> FKS ثم انها ليست فقط تحقيق وفورات في الكتابة، ولكنه يضيف وضوح إلى SQL لاستخدام فقط ID في ذلك يمكنك أن ترى بوضوح وهو <م> PK والذي هو FK .

ومنها مثلا.

ومن الموظفين الإلكترونية     LEFT JOIN العملاء ج ON e.ID = c.EmployeeID

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

Answer 4

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

Answer 5

وأنا أتفق مع كيفن وعدد قليل من غيرهم من الناس هنا أن PK لجدول ينبغي أن تكون مجرد رقم والمفاتيح الخارجية سرد OtherTable + معرف.

ولكن أود أن أضيف سبب واحد الذي أعطى مؤخرا وزنا أكبر لهذه الحجة.

في موقفي الحالي نحن توظيف إطار كيان باستخدام الجيل POCO. باستخدام اصطلاح التسمية القياسية للهوية في PK تسمح للتوريث فئة أساسية POCO مع التحقق من صحة ومثل للجداول التي تشترك في مجموعة من أسماء الأعمدة المشتركة. باستخدام TABLENAME + رقم مثل PK لكل من هذه الجداول يدمر القدرة على استخدام فئة أساسية لهذه.

وفقط بعض غذاء للفكر.

Answer 6

وانها ليست مهمة حقا، فمن المرجح أن واجهت مشاكل simalar في جميع الاتفاقيات التسمية.

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

Answer 7

وأفضله هو أيضا ID عن المفتاح الأساسي وTableNameID عن المفتاح الخارجي. وأود أيضا أن يكون لها عمود "اسم" في معظم الجداول حيث انا اقدر المستخدم قراءة معرف (أي اسم :-)) من الإدخال. هذا الهيكل يوفر قدرا كبيرا من المرونة في التطبيق نفسه، ويمكن التعامل مع الجداول في الكتلة، وبنفس الطريقة. هذا هو جدا شيء قوي. وعادة ما يتم ببناء برنامج OO فوق قاعدة البيانات، ولكن مجموعة أدوات OO لا يمكن تطبيقها لأن ديسيبل في حد ذاته لا تسمح بذلك. وجود معرف الأعمدة واسم لا تزال جيدة جدا، ولكن من هذه الخطوة.

<اقتباس فقرة>   

حدد
      i.ID، il.ID من       فواتير ط       اليسار تاريخ InvoiceLines ايل           على i.ID = il.InvoiceID

وماذا غير قادر على أن أفعل هذا؟

Select  
    Invoices.ID 
,   InvoiceLines.ID 
From
    Invoices
    Left Join InvoiceLines
        on Invoices.ID = InvoiceLines.InvoiceID

في رأيي هذا كثير جدا للقراءة وبسيطة. تسمية المتغيرات وكما قلت وايل هو خيار الفقراء بشكل عام.

Answer 8

ولقد بدأ العمل في مكان يستخدم فقط "ID" (في الجداول الأساسية، المشار إليها بواسطة TableNameID في المفاتيح الخارجية)، ولقد وجدت بالفعل اثنين من مشاكل الإنتاج تسبب مباشرة بها.

في حالة واحدة تستخدم الاستعلام "... حيث ID في (SELECT ID من OtherTable ..." بدلا من "... حيث ID في (SELECT TransID من OtherTable ...".

ويمكن لأي شخص أن يقول بصراحة انه لن يكون أسهل بكثير على الفور إذا بالكامل، واستخدمت أسماء متسقة حيث خاطئة قد قرأت "... حيث TransID في (SELECT OtherTableID من OtherTable ..."؟ I دون 'ر اعتقد ذلك.

وتحدث المشكلة الأخرى عند إعادة بيع ديون التعليمات البرمجية. إذا كنت تستخدم جدول مؤقت بينما في السابق ذهب الاستعلام على منضدة الأساسية ثم القانون القديم ما يلي: "... dbo.MyFunction (t.ID) ..." وإذا كان ذلك هو لم يتغير ولكن "تي" يشير الآن إلى جدول مؤقت بدلا من الجدول الأساسي، حتى أنك لا تحصل على خطأ - نتائج خاطئة فقط

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

Answer 9

لمصلحة من البساطة معظم الناس اسم العمود على ID الجدول. إذا كان لديه مرجعية رئيسية أجنبية على جدول آخر، ثم يدعون صراحة أنه InvoiceID (استخدام المثال الخاص بك) في حالة ينضم، كنت التعرج الجدول على أي حال حتى inv.ID صريح لا يزال أبسط من inv.InvoiceID

Answer 10

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

ومن الواضح أن الاتفاقيات تسمية غير موضوعية ويقتصر على الأسلوب. لقد وجدت ISO / IEC 11179 مبادئ توجيهية ليكون نقطة انطلاق مفيدة.

لنظم إدارة قواعد البيانات، وأنا انظر الجدولين إلى مجموعات من entites (باستثناء تلك التي يحتوي فقط من أي وقت مضى صف واحد على سبيل المثال cofig الطاولة، طاولة من الثوابت، الخ) على سبيل المثال انه سيعلن الجدول حيث بلدي employee_ID هو المفتاح Personnel. لذلك على الفور الاتفاقية TableNameID لا يعمل بالنسبة لي.

ورأيت أسلوب TableName.ID=PK TableNameID=FK المستخدمة في نماذج البيانات الكبيرة ويجب أن أقول أجد أنه من مربكة قليلا: أنا أفضل بكثير اسم معرف في أن تكون هي نفسها في جميع أنحاء أي لا تغيير اسم استنادا إلى الجدول الذي كان يحدث أن تظهر فيه. شيء هو أن نلاحظ يبدو النمط المذكور ليتم استخدامها في المحلات التجارية التي إضافة IDENTITY (زيادة تلقائية) عمود إلى <م> كل الجدول بينما يتجنبون مفاتيح الطبيعية ومركب في المفاتيح الخارجية. هذه المحلات لا تميل لقواميس البيانات الرسمية ولا بناء من نماذج البيانات. مرة أخرى، وهذا هو مجرد مسألة أسلوب واحد التي أنا لا أوافق شخصيا. حتى في نهاية المطاف، انها ليست بالنسبة لي.

وقال ان جميع، أستطيع أن أرى حالة لاسقاط أحيانا تصفيات من اسم العمود عندما يوفر اسم الجدول سياق للقيام بذلك على سبيل المثال وemployee_last_name عنصر اسمه قد تصبح مجرد last_name في الجدول Personnel. الأساس المنطقي هنا هو أن المجال "الأسماء الأخيرة الناس" وليس من المرجح أن يكون UNIONed مع الأعمدة last_name <م> من الجداول الأخرى بدلا من أن تستخدم مفتاح خارجي في آخر الجدول، ولكن بعد ذلك مرة أخرى ... أنا فقط قد أغير رأيي، وأحيانا كنت لا يمكن أبدا أن أقول. هذا هو الشيء: نمذجة البيانات هو جزء الفن والعلم جزء

.

Answer 11

أنا شخصيا تفضل (كما ذكر أعلاه) ، الجدول.معرف عن PK و TableID عن FK.حتى (من فضلك لا تبادل لاطلاق النار لي) Microsoft Access يوصي هذا.

ولكن أعرف أيضا أن بعض توليد أدوات لصالح TableID ل PK لأنها تميل إلى ربط جميع الأعمدة التي تحتوي على اسم 'ID' في كلمة ، بما في ذلك معرف!!!

حتى "مصمم الاستعلام" هل هذا على Microsoft SQL Server (و لكل استعلام إنشاء, يمكنك في نهاية المطاف تمزيق جميع لا لزوم لها حديثا العلاقات على كافة الجداول على عمود معرف)

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

وغني عن القول أن أفعل رسم خط بلدي عندما يبدأ الناس باستخدام TableName, TableDescription من هذا القبيل.في رأيي الاتفاقيات يجب القيام بما يلي:

• اسم الجدول:Pluralized.Ex. الموظفين

• الجدول المستعار:الجدول الكامل اسم singularized.Ex.

  SELECT Employee.*, eMail.Address
  FROM Employees AS Employee LEFT JOIN eMails as eMail on Employee.eMailID = eMail.eMailID -- I would sure like it to just have the eMail.ID here.... but oh well
  

[تحديث]

وهناك أيضا بعض وظائف صالحة في هذا الموضوع عن تكرار الأعمدة بسبب من "نوع من العلاقة" أو دور.سبيل المثال ، إذا كان مخزن لديه EmployeeID, يقول لي القرفصاء.حتى أنا في بعض الأحيان تفعل شيئا مثل متجر.EmployeeID_Manager.متأكد أنه أكبر قليلا ولكن في المثالب الناس لن تذهب مجنون تحاول أن تجد الجدول ManagerID, أو ما EmployeeID هو يفعل هناك.عند الاستعلام حيث سيسهل على أنها:حدد EmployeeID_Manager كما ManagerID من متجر

Answer 12

واعتقد انه يمكن استخدام أي شيء ل"ID" طالما كنت ثابت. بما في ذلك اسم الجدول المهم. أود أن أقترح استخدام أداة النمذجة مثل اروين لتنفيذ الاتفاقيات والمعايير تسمية ذلك عند كتابة استفسار فإنه من السهل أن نفهم العلاقات التي قد توجد بين الجداول.

وما أعنيه البيان الأول هو، بدلا من ID يمكنك استخدام شيء آخر مثل 'RECNO. حتى ذلك الحين هذا الجدول سيكون له PK من invoice_recno وهلم جرا.

وابتهاج، بن

Answer 13

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

 Select Invoice.InvoiceID, Lines.InvoiceLine, Customer.OrgName
 From Invoices Invoice
 Join InvoiceLines Lines on Lines.InvoiceID = Invoice.InvoiceID
 Join Customers Customer on Customer.CustomerID = Invoice.CustomerID

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

Answer 14

لاسم العمود في قاعدة البيانات، فما استقاموا لكم فاستقيموا استخدام "InvoiceID".

إذا كنت نسخ الحقول في البنية لم تسمها عبر LINQ، وأنا قد تسميته "ID" هناك، إذا كان معرف الوحيد في الهيكل.

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

Answer 15

إذا كنت تعطي كل مفتاح اسم فريد، على سبيل المثال "invoices.invoice_id" بدلا من "invoices.id"، ثم يمكنك استخدام "الانضمام طبيعية" وو"باستخدام" مشغلي مع أي مخاوف. منها مثلا.

SELECT * FROM invoices NATURAL JOIN invoice_lines
SELECT * FROM invoices JOIN invoice_lines USING (invoice_id)

وبدلا من

SELECT * from invoices JOIN invoice_lines
    ON invoices.id = invoice_lines.invoice_id

وSQL هو مطول بما فيه الكفاية دون جعلها أكثر مطول.

Answer 16

وماذا أفعل لإبقاء الأمور متسقة لنفسي (حيث لديه جدول مفتاح العمود الأساسي الوحيد استخدامه كما ID) هو اسم المفتاح الأساسي للجدول Table_pk. في أي مكان لدي لافتا المفاتيح الخارجية إلى هذا المفتاح الجداول الأولية، أسميه PrimaryKeyTable_fk العمود. وبهذه الطريقة وأنا أعلم أنه إذا كان لدي لCustomer_pk في بلدي جدول العملاء وCustomer_fk في مائدتي الأمر، وأنا أعلم أن جدول ترتيب ويشير إلى إدخال في جدول العملاء.

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

SELECT * 
FROM Customer AS c
    INNER JOIN Order AS c ON c.Customer_pk = o.Customer_fk

Answer 17

FWIW, لدينا المعيار الجديد (الذي يتغير ، أعني "تتطور" ، مع كل مشروع جديد) هو:

• حالة انخفاض قاعدة بيانات أسماء الحقول
• الأحرف الكبيرة أسماء الجداول
• استخدام ويؤكد كلمات منفصلة في اسم الحقل - تحويل هذه إلى حالة باسكال في التعليمات البرمجية.
• pk_ بادئة تعني المفتاح الأساسي
• _id لاحقة يعني عدد صحيح ، زيادة تلقائية ID
• fk_ بادئة تعني الأجنبية الرئيسية (أي لاحقة لزم الأمر)
• _VW لاحقة وجهات النظر
• is_ بادئة القيم المنطقية

لذا جدول يسمى أسماء قد الحقول pk_name_id, first_name, last_name, is_alive, و fk_company وعرض يسمى LIVING_CUSTOMERS_VW, محددة مثل:

SELECT first_name, last_name
FROM CONTACT.NAMES
WHERE (is_alive = 'True')

كما قال آخرون ، على الرغم من مجرد عن أي مخطط عمل طالما أنه ثابت و لا داع obfuscate الخاص بك المعاني.

Answer 18

وأنا أتفق بالتأكيد مع بما في ذلك اسم الجدول في اسم الحقل ID، هي نفس الأسباب التي تعطيها. عموما، هذا هو الحقل الوحيد الذي أود أن تضمين اسم الجدول.

Answer 19

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

SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceID = inv.ID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceLineID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.ID = inv.InvoiceID 
SELECT * from Invoice inv, InvoiceLine inv_l where 
inv_l.InvoiceLineID = inv.ID 

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

Answer 20

وأنا أفضل اسم المجال || 'هوية شخصية'. (أي اسم المجال + ID)

اسم المجال في كثير من الأحيان، ولكن ليس دائما، وهو نفس TABLENAME.

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

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

وأحيانا، اسم المجال || 'ID' لا يمكن استخدامها، لأنه لن يكون هناك عمودين في نفس الجدول الذي يحمل نفس الاسم. على سبيل المثال: Employees.EmployeeID وEmployees.SupervisorID. في تلك الحالات، وأنا استخدم RoleName || "ID"، كما في المثال.

وأخيرا وليس آخرا، وأنا استخدم مفاتيح الطبيعية بدلا من مفاتيح الاصطناعية عندما يكون ذلك ممكنا. هناك حالات حيث مفاتيح الطبيعية غير متوفرة أو غير جديرة بالثقة، ولكن هناك الكثير من الحالات التي يكون فيها مفتاح الطبيعي هو الخيار الصحيح. في تلك الحالات، اسمحوا لي أن تأخذ رئيسيا الطبيعي على اسم كان يمكن أن يكون طبيعيا. هذا الاسم في كثير من الأحيان حتى لا يكون الحروف، "ID" في ذلك. على سبيل المثال: OrderNo حيث لا هو اختصار ل "الرقم".

Answer 21

لكل جدول اخترت شجرة الرسالة الاختزال(مثلا ، الموظفين => Emp)

أن طريقة رقمية "ترقيم تلقائي" المفتاح الأساسي يصبح nkEmp.

أنها قصيرة وفريدة من نوعها في قاعدة البيانات بأكملها وأنا أعرف بالضبط خصائصه في لمحة.

أنا الحفاظ على نفس الأسماء في SQL و جميع اللغات يمكنني استخدام (في الغالب C#, جافا سكريبت, VB6).

Answer 22

وانظر موقع Interakt في <لأ href = "http://www.interaktonline.com/Support/Articles/Details/Design+Your+Database-Database+Naming+Convention.html؟id_art=24&id_asc=221" يختلط = "نوفولو noreferrer"> اصطلاحات التسمية للنظام مدروسة تسمية الجداول والأعمدة. الطريقة يجعل من استخدام لاحقة لكل جدول (_prd لجدول المنتج، أو _ctg لجدول فئة)، ويلحق ذلك إلى كل عمود في جدول معين. لذلك العمود هوية للجدول المنتجات سيتم id_prd وبالتالي هي فريدة من نوعها في قاعدة البيانات.

ويذهبون خطوة أخرى للمساعدة في فهم المفاتيح الخارجية: إن المفتاح الخارجي في الجدول المنتج الذي يشير إلى الجدول فئة أن idctg_prd بحيث لا يخفى على أي جدول أنها تنتمي (_prd لاحقة) والذي الجدول فإنه يشير (الفئة).

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

Answer 23

وانظر أيضا المفتاح الأساسي / الخارجية الرئيسية اصطلاح التسمية

Answer 24

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

1. استخدام قصيرة (3-4 شخصيات) ألقاب الجدول أسماء ، أيالفاتورة - inv, InvoiceLines - invl
2. اسم الأعمدة في الجدول باستخدام تلك الألقاب ، أي inv_id, invl_id
3. للإشارة الأعمدة استخدام invl_inv_id عن أسماء.

بهذه الطريقة يمكنك أن تقول

SELECT * FROM Invoice LEFT JOIN InvoiceLines ON inv_id = invl_inv_id