ما هو اصطلاح التسمية الخاص بك للإجراءات المخزنة؟[مغلق]

Question

لقد رأيت قواعد مختلفة لتسمية الإجراءات المخزنة.

يقوم بعض الأشخاص ببدء اسم sproc بـ usp_، والبعض الآخر باختصار لاسم التطبيق، والبعض الآخر باسم المالك.لا يجب عليك استخدام sp_ في SQL Server إلا إذا كنت تقصد ذلك حقًا.

يبدأ البعض اسم proc بفعل (Get، Add، Save، Remove).يؤكد آخرون على اسم (أسماء) الكيان.

في قاعدة بيانات تحتوي على مئات من sprocs، قد يكون من الصعب جدًا التنقل حولها والعثور على sprocs المناسبة عندما تعتقد أنها موجودة بالفعل.اصطلاحات التسمية يمكن أن تجعل تحديد موقع sproc أسهل.

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

ملخص الردود:

• يبدو أن الجميع يؤيدون اتساق التسمية، حيث قد يكون من المهم للجميع استخدام نفس اصطلاح التسمية بدلاً من استخدام اصطلاح معين.
• البادئات:بينما يستخدم الكثير من الأشخاص usp_ أو شيئًا مشابهًا (لكن نادرًا ما يستخدم sp_)، يستخدم العديد من الأشخاص الآخرين اسم قاعدة البيانات أو التطبيق.يستخدم أحد DBA الذكي gen وrpt وtsk للتمييز بين sprocs CRUD العامة وتلك المستخدمة لإعداد التقارير أو المهام.
• يبدو أن الفعل + الاسم أكثر شيوعًا قليلاً من الاسم + الفعل.يستخدم بعض الأشخاص كلمات SQL الأساسية (تحديد، إدراج، تحديث، حذف) للأفعال، بينما يستخدم البعض الآخر أفعالًا غير SQL (أو اختصارات لها) مثل Get وAdd.يميز البعض بين الأسماء المفردة والجمع للإشارة إلى ما إذا كان يتم استرجاع سجل واحد أو عدة سجلات.
• يتم اقتراح عبارة إضافية في النهاية، حيثما كان ذلك مناسبا.GetCustomerById، GetCustomerBySaleDate.
• يستخدم بعض الأشخاص الشرطة السفلية بين أجزاء الاسم، والبعض الآخر يتجنب الشرطة السفلية.app_ Get_Customer مقابل.appGetCustomer - أعتقد أن الأمر يتعلق بسهولة القراءة.
• يمكن فصل مجموعات كبيرة من sprocs إلى حزم Oracle أو حلول ومشروعات Management Studio (SQL Server) أو مخططات SQL Server.
• وينبغي تجنب الاختصارات الغامضة.

لماذا اخترت الإجابة فعلت: هناك الكثير من الردود الجيدة.شكرا لكم جميعا!كما ترون، سيكون من الصعب جدًا اختيار واحد فقط.الذي اخترته كان له صدى معي.لقد اتبعت نفس المسار الذي يصفه - محاولة استخدام Verb + Noun ثم عدم القدرة على العثور على جميع sprocs التي تنطبق على العميل.

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

نظرًا لأنني أعمل بشكل عام على تطبيقات كبيرة جدًا تحتوي على مئات من sprocs، فإنني أفضّل طريقة التسمية الأسهل في العثور عليها.بالنسبة لتطبيق أصغر، قد أؤيد Verb + Noun، لأنه يتبع قواعد الترميز العامة لأسماء الطرق.

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

Answer 1

بالنسبة لمشروعي الأخير، استخدمت usp_[Action][Object][Process] لذلك على سبيل المثال، usp_AddProduct أو usp_GetProductList، usp_GetProductDetail.ولكن الآن تحتوي قاعدة البيانات على 700 إجراء، ويصبح من الصعب جدًا العثور على جميع الإجراءات على كائن معين.على سبيل المثال، يتعين علي الآن البحث عن 50 إجراء إضافة فرديًا لإضافة المنتج، و50 إجراءً فرديًا للحصول على Get وما إلى ذلك.

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

الشكل الجديد هو على النحو التالي

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

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

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

Answer 2

فيما يلي بعض التوضيحات حول مشكلة البادئة sp_ في SQL Server.

الإجراءات المخزنة المسماة بالبادئة sp_ هي إجراءات النظام المخزنة في قاعدة البيانات الرئيسية.

إذا أعطيت sproc الخاص بك هذه البادئة، فإن SQL Server يبحث عنها في قاعدة البيانات الرئيسية أولاً، ثم في قاعدة بيانات السياق، وبالتالي إضاعة الموارد دون داع.وإذا كان sproc الذي أنشأه المستخدم له نفس اسم sproc النظام، فلن يتم تنفيذ sproc الذي أنشأه المستخدم.

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

هنا شرح جميل يتضمن عرضًا توضيحيًا للأداء الذي حققه.

هنا مصدر مفيد آخر مقدم من Ant في تعليق.

Answer 3

الأنظمة المجرية (مثل البادئة "usp" أعلاه) تجعلني أرتعد.

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

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

الرد على تعليق النملة:

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

Answer 4

بدء اسم الإجراء المخزن باستخدامsp_ أمر سيء في SQL Server لأن جميع sprocs النظام تبدأ بـ sp_.تعد التسمية المتسقة (حتى إلى حد hobgoblin-dom) مفيدة لأنها تسهل المهام الآلية بناءً على قاموس البيانات.تعتبر البادئات أقل فائدة قليلاً في SQL Server 2005 لأنها تدعم المخططات، والتي يمكن استخدامها لأنواع مختلفة من مساحات الأسماء بالطريقة التي كانت تستخدم بها البادئات في الأسماء.على سبيل المثال، في مخطط النجمة، يمكن للمرء أن يكون خافت و حقيقة المخططات والرجوع إلى الجداول بموجب هذه الاتفاقية.

بالنسبة للإجراءات المخزنة، تكون البادئة مفيدة لغرض تحديد sprocs التطبيق من sprocs النظام. up_ ضد. sp_ يجعل من السهل نسبياً تحديد الإجراءات المخزنة خارج النظام من قاموس البيانات.

Answer 5

TableName_WhatItDoes

• Comment_GetByID

• قائمة العملاء

• UserPreference_DeleteByUserID

لا توجد بادئات أو هراء هنغاري سخيف.فقط اسم الجدول الأكثر ارتباطًا به، ووصفًا سريعًا لما يفعله.

تحذير واحد لما سبق:أنا شخصياً أقوم دائمًا ببادئة كل ما لدي من CRUD الذي تم إنشاؤه تلقائيًا بـ zCRUD_ بحيث يتم فرزه حتى نهاية القائمة حيث لا يتعين علي إلقاء نظرة عليه.

Answer 6

لقد استخدمت تقريبًا جميع الأنظمة المختلفة على مر السنين.لقد قمت أخيرًا بتطوير هذا، والذي أستمر في استخدامه اليوم:

بادئة :

• الجنرال - عام:الخام، في الغالب
• rpt - تقرير:لا يحتاج شرح
• تسك - المهمة:عادة ما يكون هناك شيء ذو منطق إجرائي، ويتم تشغيله عبر المهام المجدولة

محدد الإجراء:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

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

هدف:

بالنسبة للجيل (CRUD)، هذا هو اسم الجدول أو طريقة العرض المتأثرة.بالنسبة لـ rpt (التقرير)، هذا هو الوصف المختصر للتقرير.بالنسبة لـ tsk (المهمة)، هذا هو الوصف المختصر للمهمة.

الموضحات الاختيارية:

هذه أجزاء اختيارية من المعلومات تُستخدم لتعزيز فهم الإجراء.تتضمن الأمثلة "بواسطة" و"من أجل" وما إلى ذلك.

شكل:

[بادئة] [محدد الإجراء] [الكيان] [الموضحات الاختيارية]

أمثلة على أسماء الإجراءات:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

Answer 7

أقوم دائمًا بتغليف الإجراءات المخزنة فيها الحزم (أنا أستخدم Oracle في العمل).سيؤدي ذلك إلى تقليل عدد الكائنات المنفصلة والمساعدة في إعادة استخدام التعليمات البرمجية.

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

Answer 8

بالنسبة لقواعد البيانات الصغيرة، أستخدم uspTableNameOperationName، على سبيل المثال.uspCustomerCreate، uspCustomerDelete، إلخ.وهذا يسهل التجميع حسب الكيان "الرئيسي".

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

أحاول تجنب الاختصارات في الأسماء من أجل الوضوح (ولا يتعين على الأشخاص الجدد في المشروع أن يتساءلوا عما يرمز إليه "UNAICFE" لأن اسم sproc يسمى uspUsingNoAbbreviationsIncreasesClarityForEveryone)

Answer 9

أستخدم حاليًا تنسيقًا يشبه ما يلي

الرموز:

[بادئة][طلب][اسم وحدة]

مثال:

P_CMS_USER_UserInfoGet

يعجبني هذا التدوين لعدة أسباب:

• البدء ببادئة بسيطة جدًا يسمح بكتابة التعليمات البرمجية لتنفيذ الكائنات التي تبدأ بالبادئة فقط (لتقليل حقن SQL، على سبيل المثال)
• في بيئتنا الأكبر، تعمل فرق متعددة على تطبيقات مختلفة تعمل بنفس بنية قاعدة البيانات.يحدد تدوين التطبيق المجموعة التي تمتلك SP.
• يكمل قسما الوحدة والاسم التسلسل الهرمي ببساطة.يجب أن تكون جميع الأسماء قابلة للمطابقة مع المجموعة/التطبيق، والوحدة، والوظيفة من التسلسل الهرمي.

Answer 10

أستخدم دائمًا:

usp[اسم الجدول][الإجراء][تفاصيل إضافية]

بالنظر إلى جدول يسمى "tblUser"، فإن هذا يعطيني:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

يتم فرز الإجراءات أبجديًا حسب اسم الجدول وحسب الوظيفة، لذلك من السهل معرفة ما يمكنني فعله بأي جدول معين.يتيح لي استخدام البادئة "usp" معرفة ما أسميه إذا كنت (على سبيل المثال) أكتب إجراءً مكونًا من 1000 سطر يتفاعل مع الإجراءات الأخرى والجداول المتعددة والوظائف وطرق العرض والخوادم.

حتى يصبح المحرر في SQL Server IDE جيدًا مثل Visual Studio سأحتفظ بالبادئات.

Answer 11

بادئة التطبيق_ بادئة العملية_ وصف كائنات قاعدة البيانات المعنية (مطروحًا منه المسافات بين الشرطات السفلية - كان عليه وضع مسافات حتى تظهر).

بادئات العملية التي نستخدمها -

• “يحصل"- إرجاع مجموعة السجلات
• “الإضافية" - إدراج البيانات
• “تحديث"- تحديث البيانات
• “ديل" - يحذف البيانات

على سبيل المثال

wmt_ins_customer_details

"أداة إدارة القوى العاملة، إدراج التفاصيل في جدول العملاء"

مزايا

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

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

لم نواجه أي عيوب لهذا النهج حتى الآن.

Answer 12

GetXXX - يحصل على XXX استنادًا إلى @ID

GetAllXXX - يحصل على كل XXX

PutXXX - يُدرج XXX إذا تم تمرير @ID وهو -1؛تحديثات أخرى

DelXXX - يحذف XXX استنادًا إلى @ID

Answer 13

أعتقد أن اصطلاح التسمية usp_ لا يفيد أحدًا.

في الماضي، كنت أستخدم بادئات Get/Update/Insert/Delete لعمليات CRUD، ولكن الآن منذ أن استخدمت Linq إلى SQL أو EF للقيام بمعظم أعمالي في CRUD، اختفت هذه البادئات تمامًا.نظرًا لأن لدي عددًا قليلاً جدًا من العمليات المخزنة في تطبيقاتي الجديدة، فإن اصطلاحات التسمية لم تعد مهمة كما كانت في السابق ؛-)

Answer 14

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

إذا لم يكن لدينا القيد القديم، فأنا متأكد تمامًا من أننا لن نستخدم البادئة.

بعد البادئة، عادة ما نبدأ اسم SP بفعل يصف ما يفعله الإجراء، ثم اسم الكيان الذي نعمل عليه.يُسمح بتعدد اسم الكيان - نحاول التأكيد على سهولة القراءة، بحيث يكون واضحًا ما يفعله الإجراء من الاسم وحده.

أسماء الإجراءات المخزنة النموذجية في فريقنا ستكون:

shopGetCategories
shopUpdateItem

Answer 15

لا أعتقد أنه من المهم حقًا ما هي البادئة الخاصة بك طالما أنك منطقي ومتسق.شخصيا أستخدم

spu _ [وصف العمل] [وصف العملية]

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

spu_archiveCollectionData 

أو

spu_setAwardStatus

أقوم بتسمية وظائفي بشكل مشابه، ولكن البادئة بـ udf_

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

Answer 16

تجنب sp_* في خادم SQl لأن جميع الإجراءات المخزنة في النظام تبدأ بـ sp_ وبالتالي يصبح من الصعب على النظام العثور على الكائن المطابق للاسم.

لذلك إذا بدأت بشيء آخر غير sp_ تصبح الأمور أسهل.

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

وبصرف النظر عن ذلك نقوم بتعيين بادئة تحدد الوظيفة.يحب

Proc_Poll_Interface, Proc_Inv_Interface إلخ.

يتيح لنا ذلك العثور على جميع العمليات المخزنة التي تقوم بمهمة POLL مقابل تلك التي تقوم بالجرد وما إلى ذلك.

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

على سبيل المثال وظيفة أخرى.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

لقد اتبعنا التسمية القائمة على الوظيفة لأن Procs تشبه الكود/الوظيفة بدلاً من الكائنات الثابتة مثل الجداول.لا يساعد Procs في العمل مع أكثر من جدول واحد.

إذا كان proc يؤدي وظائف أكثر مما يمكن التعامل معه باسم واحد، فهذا يعني أن proc الخاص بك يقوم بأكثر من اللازم بكثير، وقد حان الوقت لتقسيمها مرة أخرى.

امل ان يساعد.

Answer 17

لقد انضممت متأخرًا للموضوع ولكني أريد إدخال ردي هنا:

في مشروعي الأخيرين، كانت هناك اتجاهات مختلفة، مثل ما استخدمناه في أحد المشروعين:

للحصول على البيانات:ق<اسم الجدول>_G
لحذف البيانات:الصورة<اسم الجدول>_D
لإدراج البيانات:الصورة<اسم الجدول>_I
لتحديث البيانات:الصورة<اسم الجدول>_U

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

مثال:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

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

بينما في المشروع الثاني استخدمنا نفس اصطلاحات التسمية مع اختلاف بسيط:

للحصول على البيانات:sp_<اسم الجدول>G
لحذف البيانات:sp_<اسم الجدول>د
لإدراج البيانات:sp_<tablename>I
لتحديث البيانات:sp_<tablename>U

مثال:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU