اتفاقية التسمية التعسفية (كائنات الأعمال)

Question

حسنا، هل تفعل Business.Name أو Business.BusinessName SubCategory.ID أو SubCategory.SubCategoryID

ماذا عن في قاعدة البيانات الخاصة بك؟

لماذا؟

أنا ممزقة مع كليهما.أحب أن يكون هناك "إجابة صحيحة"

Answer 1

العيب الرئيسي لاستخدام المعرف والاسم وما إلى ذلك هو أنه يتعين عليك تأهيلهم باسم الجدول إذا كنت تكتب صلة SQL تتداخل مع جدولين.

على الرغم من ذلك، أجد أنه أكثر إيجازًا وقابلية للقراءة مجرد استخدام المعرف والاسم - سوف "يتدفق" الكود والجداول الخاصة بك بسهولة أكبر بكثير.أسهل في الكتابة وأقل تكرارا.وكتابة SELECT Business.Name FROM ...في استعلام SQL ليس أكثر إزعاجًا من كتابة SELECT BusinessName FROM ...

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

Answer 2

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

Answer 3

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

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

Answer 4

نحن نقوم بمعرفة أي شيء يمثل المفتاح الأساسي.يبدو أن قول SubCategory.SubCategoryID لا لزوم له،

Answer 5

قد لا أكون على حق، ولكن أعتقد أن طبق "إد" ألذ.

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

أما بالنسبة للآخر، فهذا هو التفضيل الكامل ولا أرى أي آثار حقيقية بخلاف الوقت الضائع في كتابة الأحرف الأخرى، و.net لذلك لا أحد يكتب مساحات الأسماء على أي حال.