หลักการตั้งชื่อของคุณสำหรับขั้นตอนการจัดเก็บคืออะไร? [ปิด]

ฉันได้เห็นกฎต่างๆสำหรับการตั้งชื่อกระบวนงานที่เก็บไว้

บางคนนำหน้าชื่อ sproc ด้วย usp_ คนอื่น ๆ ใช้ตัวย่อของชื่อแอปและคนอื่น ๆ ยังมีชื่อเจ้าของ คุณไม่ควรใช้ sp_ ใน SQL Server เว้นแต่คุณจะตั้งใจจริง

บางคนเริ่มต้นชื่อ proc ด้วยคำกริยา (Get, Add, Save, Remove) อื่น ๆ เน้นชื่อเอนทิตี

ในฐานข้อมูลที่มี sprocs หลายร้อย sprocs อาจเป็นเรื่องยากมากที่จะเลื่อนดูและค้นหา sproc ที่เหมาะสมเมื่อคุณคิดว่ามีอยู่แล้ว รูปแบบการตั้งชื่อสามารถทำให้การค้นหา sproc ง่ายขึ้น

คุณใช้หลักการตั้งชื่อหรือไม่? โปรดอธิบายและอธิบายเหตุผลที่คุณชอบมากกว่าตัวเลือกอื่น ๆ

สรุปคำตอบ:

• ดูเหมือนว่าทุกคนจะสนับสนุนความสอดคล้องของการตั้งชื่อซึ่งอาจสำคัญกว่าที่ทุกคนจะต้องใช้รูปแบบการตั้งชื่อแบบเดียวกันมากกว่าที่จะใช้
• คำนำหน้า: ในขณะที่ผู้คนจำนวนมากใช้ usp_ หรือสิ่งที่คล้ายกัน (แต่ไม่ค่อยมี sp_) แต่คนอื่น ๆ ก็ใช้ฐานข้อมูลหรือชื่อแอป DBA ที่ชาญฉลาดตัวหนึ่งใช้ gen, rpt และ tsk เพื่อแยกความแตกต่างของ CRUD sprocs ทั่วไปจากที่ใช้สำหรับการรายงานหรืองาน
• Verb + Noun น่าจะได้รับความนิยมมากกว่า Noun + Verb เล็กน้อย บางคนใช้คำหลัก SQL (เลือกแทรกอัปเดตลบ) สำหรับคำกริยาในขณะที่บางคนใช้คำกริยาที่ไม่ใช่ SQL (หรือคำย่อสำหรับพวกเขา) เช่น Get and Add บางคนแยกความแตกต่างระหว่างคำนามเอกพจน์และคำนามพหูพจน์เพื่อระบุว่ากำลังเรียกข้อมูลหนึ่งหรือหลายรายการ
• มีการแนะนำวลีเพิ่มเติมในตอนท้ายตามความเหมาะสม GetCustomerById, GetCustomerBySaleDate
• บางคนใช้เครื่องหมายขีดล่างระหว่างส่วนของชื่อและบางคนก็หลีกเลี่ยงการขีดล่าง app_ Get_Customer กับ appGetCustomer - ฉันเดาว่ามันเป็นเรื่องของการอ่าน
• คอลเล็กชัน sprocs จำนวนมากสามารถแยกออกเป็นแพ็คเกจ Oracle หรือโซลูชันและโครงการ Management Studio (SQL Server) หรือสคีมาของ SQL Server
• ควรหลีกเลี่ยงตัวย่อที่แทรกซึมได้

ทำไมฉันถึงเลือกคำตอบที่ฉันทำ:มีคำตอบที่ดีมากมาย ขอบคุณทุกคน! อย่างที่คุณเห็นมันยากมากที่จะเลือกเพียงอย่างเดียว สิ่งที่ฉันเลือกสะท้อนกับฉัน ฉันได้ทำตามเส้นทางเดียวกับที่เขาอธิบาย - พยายามใช้คำกริยา + คำนามแล้วไม่พบ sprocs ทั้งหมดที่เกี่ยวข้องกับลูกค้า

ความสามารถในการค้นหา sproc ที่มีอยู่หรือเพื่อตรวจสอบว่ามีอยู่หรือไม่นั้นสำคัญมาก ปัญหาร้ายแรงอาจเกิดขึ้นได้หากมีคนสร้าง sproc ที่ซ้ำกันโดยไม่ได้ตั้งใจด้วยชื่ออื่น

เนื่องจากโดยทั่วไปฉันทำงานกับแอปขนาดใหญ่ที่มี sprocs หลายร้อยรายการฉันจึงชอบวิธีการตั้งชื่อที่ง่ายที่สุดในการค้นหา สำหรับแอปขนาดเล็กฉันอาจสนับสนุน Verb + Noun เนื่องจากเป็นไปตามรูปแบบการเข้ารหัสทั่วไปสำหรับชื่อเมธอด

นอกจากนี้เขายังสนับสนุนการเติมคำนำหน้าด้วยชื่อแอปแทน usp_ ที่ไม่เป็นประโยชน์ ตามที่หลายคนชี้ให้เห็นบางครั้งฐานข้อมูลมี sprocs สำหรับหลายแอพ ดังนั้นการขึ้นต้นด้วยชื่อแอปจึงช่วยแยก sprocs และช่วย DBA และอื่น ๆ ในการพิจารณาว่าจะใช้ sproc สำหรับแอปใด

สำหรับโครงการล่าสุดของฉันฉันใช้ usp_ [Action] [Object] [Process] ดังนั้นตัวอย่างเช่น usp_AddProduct หรือ usp_GetProductList, usp_GetProductDetail อย่างไรก็ตามตอนนี้ฐานข้อมูลอยู่ที่ 700 โพรซีเดอร์บวกกับการค้นหาโพรซีเดอร์ทั้งหมดบนออบเจ็กต์เฉพาะได้ยากขึ้นมาก ตัวอย่างเช่นตอนนี้ฉันต้องค้นหา 50 odd Add Procedure สำหรับ Product add และ 50 odd สำหรับ Get เป็นต้น

ด้วยเหตุนี้ในแอปพลิเคชันใหม่ของฉันฉันกำลังวางแผนที่จะจัดกลุ่มชื่อโพรซีเดอร์ตามอ็อบเจ็กต์ฉันจึงทิ้ง usp ด้วยเพราะฉันรู้สึกว่ามันค่อนข้างซ้ำซ้อนนอกเหนือจากการบอกขั้นตอนของมันฉันสามารถหักออกจากชื่อของ ขั้นตอนเอง

รูปแบบใหม่มีดังนี้

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

ช่วยจัดกลุ่มสิ่งต่างๆเพื่อให้ค้นหาได้ง่ายขึ้นในภายหลังโดยเฉพาะอย่างยิ่งหากมี sprocs จำนวนมาก

เกี่ยวกับตำแหน่งที่ใช้มากกว่าหนึ่งอ็อบเจ็กต์ฉันพบว่าอินสแตนซ์ส่วนใหญ่มีอ็อบเจ็กต์หลักและรองดังนั้นอ็อบเจ็กต์หลักจึงถูกใช้ในอินสแตนซ์ปกติและรองจะถูกอ้างถึงในส่วนกระบวนการตัวอย่างเช่น App_Product_AddAttribute

นี่คือคำชี้แจงบางส่วนเกี่ยวกับปัญหาคำนำหน้า sp_ ใน SQL Server

โพรซีเดอร์ที่จัดเก็บที่ตั้งชื่อด้วยคำนำหน้า sp_ คือ sprocs ระบบที่เก็บไว้ในฐานข้อมูลหลัก

หากคุณให้คำนำหน้า sproc นี้ SQL Server จะค้นหาสิ่งเหล่านี้ในฐานข้อมูลหลักก่อนจากนั้นฐานข้อมูลบริบทจึงสิ้นเปลืองทรัพยากรโดยไม่จำเป็น และถ้า sproc ที่ผู้ใช้สร้างขึ้นมีชื่อเดียวกันกับ sproc ระบบ sproc ที่ผู้ใช้สร้างขึ้นจะไม่ถูกเรียกใช้งาน

คำนำหน้า sp_ ระบุว่า sproc สามารถเข้าถึงได้จากฐานข้อมูลทั้งหมด แต่ควรดำเนินการในบริบทของฐานข้อมูลปัจจุบัน

นี่เป็นคำอธิบายที่ดีซึ่งรวมถึงการสาธิตการตี

นี่คือแหล่งข้อมูลที่เป็นประโยชน์อีกแห่งที่ Ant ให้ไว้ในความคิดเห็น

ระบบฮังการี (เช่นคำนำหน้า "usp" ด้านบน) ทำให้ฉันหวั่นไหว

เราแชร์โพรซีเดอร์ที่จัดเก็บไว้จำนวนมากในฐานข้อมูลที่แตกต่างกันและมีโครงสร้างคล้ายกันดังนั้นสำหรับฐานข้อมูลเฉพาะเราใช้คำนำหน้าของชื่อฐานข้อมูล ขั้นตอนที่ใช้ร่วมกันไม่มีคำนำหน้า ฉันคิดว่าการใช้สคีมาที่แตกต่างกันอาจเป็นอีกทางเลือกหนึ่งในการกำจัดคำนำหน้าที่ค่อนข้างน่าเกลียดออกไปทั้งหมด

ชื่อจริงหลังคำนำหน้าแทบจะไม่แตกต่างจากการตั้งชื่อฟังก์ชัน: โดยทั่วไปเป็นคำกริยาเช่น "Add", "Set", "Generate", "Calculate", "Delete" ฯลฯ ตามด้วยคำนามเฉพาะอื่น ๆ เช่น "User "," DailyRevenues "และอื่น ๆ

การตอบกลับความคิดเห็นของ Ant:

1. ความแตกต่างระหว่างตารางและมุมมองเกี่ยวข้องกับผู้ที่ออกแบบสคีมาฐานข้อมูลไม่ใช่ผู้ที่เข้าถึงหรือแก้ไขเนื้อหา ในกรณีที่ไม่ค่อยต้องการข้อมูลจำเพาะของสคีมาก็หาได้ง่าย สำหรับแบบสอบถาม SELECT แบบไม่เป็นทางการจะไม่เกี่ยวข้อง อันที่จริงฉันถือว่าความสามารถในการปฏิบัติต่อตารางและมุมมองเหมือนกับข้อได้เปรียบที่ยิ่งใหญ่
2. ไม่เหมือนกับฟังก์ชันและขั้นตอนการจัดเก็บชื่อของตารางหรือมุมมองไม่น่าจะขึ้นต้นด้วยคำกริยาหรือเป็นอะไรก็ได้นอกจากคำนามหนึ่งคำขึ้นไป
3. ฟังก์ชันต้องการคำนำหน้าสคีมาเพื่อเรียกใช้ ในความเป็นจริงไวยากรณ์การโทร (ที่เราใช้อยู่) นั้นแตกต่างกันมากระหว่างฟังก์ชันและกระบวนงานที่เก็บไว้ แต่ถึงแม้ว่าจะไม่ใช่เช่นเดียวกับ 1. ก็ใช้ได้: ถ้าฉันสามารถใช้ฟังก์ชันและโพรซีเดอร์ที่จัดเก็บได้เหมือนเดิมทำไมฉันไม่ควร?

ฉันได้ใช้ระบบต่างๆทั้งหมดในช่วงหลายปีที่ผ่านมา ในที่สุดฉันก็พัฒนาอันนี้ซึ่งฉันยังคงใช้อยู่จนถึงทุกวันนี้:

คำนำหน้า:

• gen - ทั่วไป: CRUD ส่วนใหญ่
• rpt - รายงาน: อธิบายตนเอง
• tsk - งาน: มักจะเป็นสิ่งที่มีตรรกะขั้นตอนเรียกใช้ผ่านงานที่กำหนดเวลาไว้

ตัวระบุการดำเนินการ:

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

(ในกรณีที่ขั้นตอนดำเนินการหลายอย่างเป้าหมายโดยรวมจะใช้ในการเลือกตัวระบุการดำเนินการตัวอย่างเช่น INSERT ของลูกค้าอาจต้องการการเตรียมงานที่ดี แต่เป้าหมายโดยรวมคือ INSERT ดังนั้นจึงเลือก "Ins"

วัตถุ:

สำหรับ gen (CRUD) นี่คือตารางหรือชื่อมุมมองที่ได้รับผลกระทบ สำหรับ rpt (รายงาน) นี่คือคำอธิบายสั้น ๆ ของรายงาน สำหรับ tsk (งาน) นี่คือคำอธิบายสั้น ๆ ของงาน

Clarifiers เสริม:

ข้อมูลเหล่านี้เป็นข้อมูลเสริมที่ใช้เพื่อเพิ่มความเข้าใจในขั้นตอน ตัวอย่าง ได้แก่ "By" "For" เป็นต้น

รูปแบบ:

[คำนำหน้า] [ตัวระบุการดำเนินการ] [เอนทิตี] [Clarifiers เสริม]

ตัวอย่างชื่อกระบวนงาน:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• CUSTOMER_LIST

• UserPreference_DeleteByUserID

ไม่มีคำนำหน้าหรือเรื่องไร้สาระฮังการีโง่ ๆ เพียงแค่ชื่อของตารางที่เกี่ยวข้องมากที่สุดและคำอธิบายสั้น ๆ ว่ามันทำอะไร

ข้อแม้ประการหนึ่งข้างต้น: โดยส่วนตัวแล้วฉันมักจะเติมคำนำหน้า CRUD ที่สร้างขึ้นโดยอัตโนมัติทั้งหมดของฉันด้วย zCRUD_ เพื่อให้อยู่ในส่วนท้ายของรายการโดยที่ฉันไม่ต้องดู

การเริ่มต้นชื่อกระบวนงานที่เก็บไว้ด้วยsp_ไม่ถูกต้องใน SQL Server เนื่องจากระบบ sprocs ทั้งหมดเริ่มต้นด้วย sp_ การตั้งชื่อที่สอดคล้องกัน (ถึงขนาด hobgoblin-dom) มีประโยชน์เพราะช่วยอำนวยความสะดวกในการทำงานอัตโนมัติตามพจนานุกรมข้อมูล คำนำหน้ามีประโยชน์น้อยกว่าเล็กน้อยใน SQL Server 2005 เนื่องจากสนับสนุนสกีมาซึ่งสามารถใช้กับเนมสเปซประเภทต่างๆในลักษณะที่ใช้คำนำหน้าชื่อ ตัวอย่างเช่นในสคีดาวหนึ่งอาจมีสลัวและความเป็นจริง schemas และการอ้างอิงถึงตารางโดยการประชุมนี้

สำหรับโพรซีเดอร์ที่จัดเก็บการเติมคำนำหน้ามีประโยชน์สำหรับวัตถุประสงค์ในการระบุ sprocs ของแอปพลิเคชันจาก sprocs ระบบ up_เทียบกับsp_ทำให้ง่ายต่อการระบุขั้นตอนการจัดเก็บที่ไม่ใช่ระบบจากพจนานุกรมข้อมูล

ฉันห่อหุ้มโพรซีเดอร์ที่จัดเก็บไว้ในแพ็คเกจเสมอ (ฉันใช้ Oracle ในที่ทำงาน) ซึ่งจะช่วยลดจำนวนวัตถุที่แยกจากกันและช่วยให้ใช้รหัสซ้ำได้

หลักการตั้งชื่อเป็นเรื่องของรสนิยมและเป็นสิ่งที่คุณควรเห็นด้วยกับนักพัฒนาคนอื่น ๆ ทั้งหมดเมื่อเริ่มโครงการ

สำหรับฐานข้อมูลขนาดเล็กฉันใช้ uspTableNameOperationName เช่น uspCustomerCreate, uspCustomerDelete เป็นต้นสิ่งนี้อำนวยความสะดวกในการจัดกลุ่มตามเอนทิตี 'หลัก'

สำหรับฐานข้อมูลขนาดใหญ่ให้เพิ่มสคีมาหรือชื่อระบบย่อยเช่นการรับการจัดซื้อ ฯลฯ เพื่อจัดกลุ่มไว้ด้วยกัน (เนื่องจากเซิร์ฟเวอร์ sql ชอบแสดงตามตัวอักษร)

ฉันพยายามหลีกเลี่ยงตัวย่อในชื่อเพื่อความชัดเจน (และผู้คนใหม่ ๆ ในโครงการไม่ต้องสงสัยว่า 'UNAICFE' หมายถึงอะไรเพราะ sproc มีชื่อว่า uspUsingNoAbcribIncreasesClarityForEveryone)

ฉันกำลังใช้รูปแบบที่เป็นดังต่อไปนี้

โน้ต:

[PREFIX] [APPLICATION] [MODULE] _ [NAME]

ตัวอย่าง:

P_CMS_USER_UserInfoGet

ฉันชอบสัญกรณ์นี้ด้วยเหตุผลบางประการ:

• เริ่มต้นด้วยคำนำหน้าอย่างง่ายมากอนุญาตให้เขียนโค้ดเพื่อเรียกใช้งานวัตถุที่เริ่มต้นด้วยคำนำหน้าเท่านั้น (เพื่อลดการแทรก SQL เป็นต้น)
• ในสภาพแวดล้อมที่ใหญ่ขึ้นของเราทีมงานหลายทีมกำลังทำงานกับแอพต่างๆที่ใช้สถาปัตยกรรมฐานข้อมูลเดียวกัน สัญกรณ์แอปพลิเคชันกำหนดว่ากลุ่มใดเป็นเจ้าของ SP
• ส่วนโมดูลและชื่อเพียงแค่กรอกมรดก ชื่อทั้งหมดควรสามารถจับคู่กับ Group / App, Module, Function จาก heirarchy

ฉันมักจะใช้:

usp [ชื่อตาราง] [การดำเนินการ] [รายละเอียดเพิ่มเติม]

ตารางที่เรียกว่า "tblUser" ทำให้ฉัน:

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

ขั้นตอนต่างๆเรียงตามตัวอักษรตามชื่อตารางและตามฟังก์ชันการทำงานดังนั้นจึงง่ายต่อการดูว่าฉันสามารถทำอะไรกับตารางใดก็ได้ การใช้คำนำหน้า "usp" ทำให้ฉันรู้ว่าฉันกำลังเรียกอะไรถ้าฉัน (ตัวอย่าง) เขียนโพรซีเดอร์ 1,000 บรรทัดที่โต้ตอบกับโพรซีเดอร์อื่น ๆ ตารางหลายฟังก์ชันมุมมองและเซิร์ฟเวอร์

จนกว่าตัวแก้ไขใน SQL Server IDE จะดีเท่ากับ Visual Studio ฉันจะรักษาคำนำหน้าไว้

แอพลิเคชัน prefix_ รายละเอียดการดำเนินงาน prefix_ ของฐานข้อมูลที่เกี่ยวข้องกับวัตถุ(ลบช่องว่างระหว่างขีด - มีการใส่ช่องว่างในสำหรับพวกเขาที่จะปรากฏ)

คำนำหน้าการดำเนินการที่เราใช้ -

• “ get ” - ส่งคืนชุดระเบียน
• “ ins ” - แทรกข้อมูล
• “ พีดี ” - ปรับปรุงข้อมูล
• “ del ” - ลบข้อมูล

เช่น

wmt_ ins _ ลูกค้า _ รายละเอียด

"เครื่องมือการจัดการพนักงานแทรกรายละเอียดในตารางลูกค้า"

ข้อได้เปรียบ

กระบวนงานที่จัดเก็บทั้งหมดที่เกี่ยวข้องกับแอปพลิเคชันเดียวกันจะถูกจัดกลุ่มเข้าด้วยกันตามชื่อ ภายในกลุ่มขั้นตอนการจัดเก็บที่ดำเนินการประเภทเดียวกัน (เช่นการแทรกการอัปเดต ฯลฯ ) จะถูกจัดกลุ่มเข้าด้วยกัน

ระบบนี้ทำงานได้ดีสำหรับเราโดยมีประมาณ 1,000 กระบวนงานที่เก็บไว้ในฐานข้อมูลเดียวจากด้านบนของหัวของฉัน

จนถึงขณะนี้ยังไม่พบข้อเสียใด ๆ ของแนวทางนี้

GetXXX - รับ XXX ตาม @ID

GetAllXXX - รับ XXX ทั้งหมด

PutXXX - แทรก XXX ถ้าผ่าน @ID คือ -1; การอัปเดตอื่น ๆ

DelXXX - ลบ XXX ตาม @ID

ฉันคิดว่าหลักการตั้งชื่อ usp_ ไม่มีใครดี

ในอดีตฉันเคยใช้คำนำหน้ารับ / อัปเดต / แทรก / ลบสำหรับการดำเนินการ CRUD แต่ตอนนี้เนื่องจากฉันใช้ Linq กับ SQL หรือ EF เพื่อทำงาน CRUD ส่วนใหญ่สิ่งเหล่านี้จึงหายไปทั้งหมด เนื่องจากฉันมี procs ที่จัดเก็บไว้น้อยมากในแอปพลิเคชันใหม่ของฉันรูปแบบการตั้งชื่อจึงไม่สำคัญเหมือนที่เคยทำอีกต่อไป ;-)

สำหรับแอปพลิเคชันปัจจุบันที่ฉันกำลังใช้งานอยู่เรามีคำนำหน้าที่ระบุชื่อแอปพลิเคชัน (ตัวพิมพ์เล็กสี่ตัว) เหตุผลก็คือแอปพลิเคชันของเราจะต้องสามารถอยู่ร่วมกับแอปพลิเคชันเดิมในฐานข้อมูลเดียวกันได้ดังนั้นจึงต้องมีคำนำหน้า

หากเราไม่มีข้อ จำกัด เดิมฉันค่อนข้างแน่ใจว่าเราจะไม่ใช้คำนำหน้า

หลังจากคำนำหน้าเรามักจะเริ่มต้นชื่อ SP ด้วยคำกริยาที่อธิบายว่าขั้นตอนทำอะไรแล้วตามด้วยชื่อของเอนทิตีที่เราดำเนินการ อนุญาตให้ใช้ชื่อเอนทิตีแบบพหูพจน์ได้ - เราพยายามเน้นความสามารถในการอ่านได้เพื่อให้เห็นได้ชัดว่าขั้นตอนทำอะไรจากชื่อเพียงอย่างเดียว

ชื่อกระบวนงานที่จัดเก็บโดยทั่วไปในทีมของเราจะเป็น:

shopGetCategories
shopUpdateItem

ฉันไม่คิดว่ามันสำคัญจริงๆว่าคำนำหน้าของคุณคืออะไรตราบเท่าที่คุณมีเหตุผลและสอดคล้องกัน ส่วนตัวผมใช้

spu_ [คำอธิบายการดำเนินการ] [คำอธิบายกระบวนการ]

โดยที่คำอธิบายการดำเนินการเป็นหนึ่งในช่วงเล็ก ๆ ของการดำเนินการทั่วไปเช่น get, set, archive, insert, delete เป็นต้นคำอธิบายกระบวนการเป็นสิ่งที่สั้น แต่อธิบายได้ง่ายเช่น

spu_archiveCollectionData 

หรือ

spu_setAwardStatus

ฉันตั้งชื่อฟังก์ชั่นของฉันในทำนองเดียวกัน แต่นำหน้าด้วย udf_

ฉันเคยเห็นคนพยายามใช้สัญกรณ์หลอกฮังการีสำหรับการตั้งชื่อขั้นตอนซึ่งในความคิดของฉันซ่อนมากกว่าที่เปิดเผย ตราบเท่าที่ฉันแสดงรายการขั้นตอนตามตัวอักษรฉันสามารถเห็นพวกเขาจัดกลุ่มตามฟังก์ชันการทำงานสำหรับฉันแล้วสำหรับฉันที่ดูเหมือนจะเป็นจุดที่ดีระหว่างคำสั่งและความเข้มงวดที่ไม่จำเป็น

หลีกเลี่ยง sp_ * ในเซิร์ฟเวอร์ SQl เนื่องจาก prcedures ที่จัดเก็บของระบบทั้งหมดเริ่มต้นด้วย sp_ ดังนั้นระบบจะค้นหาวัตถุที่ตรงกับชื่อได้ยากขึ้น

ดังนั้นหากคุณเริ่มต้นด้วยสิ่งอื่นที่ไม่ใช่ sp_ สิ่งต่างๆจะง่ายขึ้น

ดังนั้นเราจึงใช้การตั้งชื่อทั่วไปของ Proc_ เพื่อเริ่มต้นด้วย ทำให้ง่ายต่อการระบุขั้นตอนหากนำเสนอด้วยไฟล์สคีมาขนาดใหญ่หนึ่งไฟล์

นอกเหนือจากนั้นเรายังกำหนดคำนำหน้าที่ระบุฟังก์ชัน ชอบ

Proc_Poll_Interface, Proc_Inv_Interface เป็นต้น

สิ่งนี้ช่วยให้เราสามารถค้นหา procs ที่เก็บไว้ทั้งหมดซึ่งทำงานของ POLL เทียบกับที่ทำ Inventory เป็นต้น

ระบบคำนำหน้าขึ้นอยู่กับโดเมนปัญหาของคุณ แต่อัลพูดและทำสิ่งที่คล้ายกันควรนำเสนอแม้ว่าจะเป็นเพียงการอนุญาตให้ผู้คนค้นหาขั้นตอนการจัดเก็บในแบบเลื่อนลง explorere เพื่อแก้ไข

เช่นอื่น ๆ ของฟังก์ชัน

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

เราติดตามฟังก์ชั่นการตั้งชื่อ coz Procs คล้ายกับรหัส / ฟังก์ชันมากกว่าวัตถุคงที่เช่นตาราง ไม่ได้ช่วยอะไรที่ Procs อาจทำงานกับตารางมากกว่าหนึ่งตาราง

หาก proc ทำหน้าที่มากกว่าที่จะจัดการได้ในชื่อเดียวนั่นหมายความว่า proc ของคุณทำงานเกินความจำเป็นและถึงเวลาที่จะแยกพวกมันอีกครั้ง

หวังว่าจะช่วยได้

ฉันเข้าร่วมกระทู้ช้า แต่ต้องการตอบกลับที่นี่:

ในสองโครงการสุดท้ายของฉันมีแนวโน้มที่แตกต่างกันเช่นในโครงการที่เราใช้:

ในการรับข้อมูล: s <tablename> _G
ในการลบข้อมูล: s <tablename> _D
ในการแทรกข้อมูล: s <tablename> _I
ในการอัปเดตข้อมูล: s <tablename> _U

การตั้งชื่อนี้ยังใช้ใน front-end โดย prefixing คำdt

ตัวอย่าง:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

ด้วยความช่วยเหลือของรูปแบบการตั้งชื่อข้างต้นในแอปพลิเคชันของเราเรามีชื่อที่ดีและจำง่าย

ในโครงการที่สองเราใช้หลักการตั้งชื่อเดียวกันกับความแตกต่าง:

ในการรับข้อมูล: sp_ <tablename> G
ในการลบข้อมูล: sp_ <tablename> D
ในการแทรกข้อมูล: sp_ <tablename> I
เพื่ออัปเดตข้อมูล: sp_ <tablename> U

ตัวอย่าง:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU