Quy ước đặt tên của bạn cho các thủ tục được lưu trữ là gì? [đóng cửa]


122

Tôi đã thấy các quy tắc khác nhau để đặt tên cho các thủ tục được lưu trữ.

Một số người đặt tiền tố tên mầm bằng usp_, những người khác viết tắt tên ứng dụng và những người khác vẫn có tên chủ sở hữu. Bạn không nên sử dụng sp_ trong SQL Server trừ khi bạn thực sự có ý đó.

Một số bắt đầu tên proc bằng một động từ (Nhận, Thêm, Lưu, Loại bỏ). Những người khác nhấn mạnh (các) tên thực thể.

Trên một cơ sở dữ liệu với hàng trăm loại mầm, có thể rất khó để cuộn xung quanh và tìm một loại mầm phù hợp khi bạn nghĩ rằng một loại đã tồn tại. Quy ước đặt tên có thể làm cho việc xác định vị trí một mầm dễ dàng hơn.

Bạn có sử dụng quy ước đặt tên không? Vui lòng mô tả nó và giải thích tại sao bạn thích nó hơn các lựa chọn khác.

Tóm tắt các câu trả lời:

  • Mọi người dường như ủng hộ sự nhất quán của việc đặt tên, rằng mọi người sử dụng cùng một quy ước đặt tên có thể quan trọng hơn so với quy ước đặt tên cụ thể nào.
  • Tiền tố: Trong khi nhiều người sử dụng usp_ hoặc một cái gì đó tương tự (nhưng hiếm khi sp_), nhiều người khác sử dụng cơ sở dữ liệu hoặc tên ứng dụng. Một DBA thông minh sử dụng gen, rpt và tsk để phân biệt các mầm CRUD chung với các mầm được sử dụng để báo cáo hoặc nhiệm vụ.
  • Động từ + Danh từ có vẻ phổ biến hơn một chút so với Danh từ + Động từ. Một số người sử dụng các từ khóa SQL (Chọn, Chèn, Cập nhật, Xóa) cho các động từ, trong khi những người khác sử dụng các động từ không phải SQL (hoặc viết tắt cho chúng) như Nhận và Thêm. Một số phân biệt giữa danh từ đơn và danh từ số nhiều để cho biết liệu một hoặc nhiều bản ghi đang được truy xuất.
  • Một cụm từ bổ sung được đề xuất ở cuối, nếu thích hợp. GetCustomerById, GetCustomerBySaleDate.
  • Một số người sử dụng dấu gạch dưới giữa các phân đoạn tên và một số người tránh dấu gạch dưới. app_ Get_Customer so với appGetCustomer - Tôi đoán đó là vấn đề dễ đọc.
  • Các tập hợp lớn các mầm có thể được tách biệt thành các gói Oracle hoặc các giải pháp và dự án Management Studio (SQL Server) hoặc các lược đồ SQL Server.
  • Nên tránh những chữ viết tắt khó hiểu.

Tại sao tôi chọn câu trả lời Tôi đã làm: Có rất nhiều câu trả lời tốt. Cảm ơn tất cả! Như bạn thấy, sẽ rất khó để chọn chỉ một. Một trong những tôi chọn đã gây tiếng vang cho tôi. Tôi đã đi theo con đường giống như anh ấy mô tả - cố gắng sử dụng Động từ + Danh từ và sau đó không thể tìm thấy tất cả các mầm áp dụng cho Khách hàng.

Có thể xác định vị trí một mầm hiện có, hoặc xác định xem một cái còn tồn tại hay không, là rất quan trọng. Các vấn đề nghiêm trọng có thể phát sinh nếu ai đó vô tình tạo ra một mầm cây trùng lặp với tên khác.

Vì tôi thường làm việc trên các ứng dụng rất lớn với hàng trăm loại mầm, nên tôi thích cách đặt tên dễ tìm nhất. Đối với một ứng dụng nhỏ hơn, tôi có thể ủng hộ Động từ + Danh từ, vì nó tuân theo quy ước mã hóa chung cho tên phương thức.

Anh ấy cũng ủng hộ việc đặt tiền tố bằng tên ứng dụng thay vì usp_ không hữu ích lắm. Như một số người đã chỉ ra, đôi khi cơ sở dữ liệu chứa các mầm cho nhiều ứng dụng. Vì vậy, tiền tố với tên ứng dụng giúp tách biệt các mầm và giúp DBA và những người khác xác định ứng dụng mà mầm được sử dụng.


1
Usp là viết tắt của gì?
Giữa

2
Tôi tin rằng usp là viết tắt của "thủ tục người dùng". Điều đó phân biệt nó với các thủ tục hệ thống có tiền tố "sp_". Đó là một sự khác biệt quan trọng, như bạn có thể đọc trong câu trả lời.
DOK

cảm ơn dok. grazie mille
Midhat


1
Tôi ủng hộ điều này chỉ vì nó đã đóng cửa, hy vọng sẽ cho thấy sức mạnh của những câu hỏi như thế này hữu ích cho cộng đồng.
tsilb

Câu trả lời:


66

Đối với dự án cuối cùng của tôi, tôi đã sử dụng usp_ [Hành động] [Đối tượng] [Quy trình], ví dụ: usp_AddProduct hoặc usp_GetProductList, usp_GetProductDetail. Tuy nhiên hiện nay cơ sở dữ liệu đã ở mức 700 thủ tục cộng với việc tìm kiếm tất cả các thủ tục trên một đối tượng cụ thể trở nên khó hơn rất nhiều. Ví dụ: bây giờ tôi phải tìm kiếm 50 thủ tục Thêm lẻ cho Sản phẩm thêm và 50 lẻ cho Lấy, v.v.

Vì điều này trong ứng dụng mới của tôi, tôi đang lên kế hoạch nhóm các tên thủ tục theo đối tượng, tôi cũng bỏ usp vì tôi cảm thấy nó hơi thừa, ngoài việc cho tôi biết một thủ tục của nó, một thứ gì đó tôi có thể trừ khỏi tên của thủ tục chính nó.

Định dạng mới như sau

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

Nó giúp nhóm mọi thứ để tìm kiếm dễ dàng hơn sau này, đặc biệt nếu có một lượng lớn rau mầm.

Về nơi nhiều hơn một đối tượng được sử dụng, tôi thấy rằng hầu hết các phiên bản đều có một đối tượng chính và phụ, vì vậy đối tượng chính được sử dụng trong phiên bản bình thường và đối tượng phụ được tham chiếu đến trong phần quy trình, ví dụ: App_Product_AddAttribute.


3
Điều gì xảy ra nếu có nhiều Đối tượng tham gia? Ví dụ: điều gì sẽ xảy ra nếu mầm non truy vấn thông tin từ cả bảng Khách hàng và Đơn hàng?
DOK

2
Cảm ơn Mitch, chúng ta hãy làm rõ. Tiền tố "Ứng dụng" đó là phần giữ chỗ cho một chữ viết tắt khác cho biết tên (hoặc từ viết tắt) của ứng dụng thực tế. Khi đó, với 3 ứng dụng chia sẻ một cơ sở dữ liệu, có thể có ICA_Product_Add, CRM_Product_Add và BPS_Product_Add.
DOK

2
Tại sao bạn lại lặp lại mọi quy trình 3 lần cho 3 ứng dụng? Toàn bộ điểm của Thủ tục Cửa hàng là có một nơi duy nhất để xảy ra một hành động nhất định. "ICA_Product_Add, CRM_Product_Add và BPS_Product_Add" phá hủy điều đó.
Jason Kester

3
Jason, những mầm đó có thể đang chèn vào các bảng khác nhau. Chúng có thể có các tham số đầu vào hoặc giá trị trả về khác nhau. Hoặc họ có thể có hành vi khác nhau. Tôi đồng ý rằng nếu các mầm làm được điều tương tự, chỉ nên có một phiên bản. Như ai đó đã đề xuất, rau mầm được chia sẻ có thể không có tiền tố.
DOK

1
Nếu bạn có nhiều ứng dụng gọi cùng một quy trình thì bạn cần phải hết sức cẩn thận, bất kỳ sửa đổi nào đối với proc đó có thể phá vỡ nhiều ứng dụng đó. Đặt tên khôn ngoan, nó là một vùng màu xám, nhưng bạn có thể đặt tên nó là chung / toàn cầu hoặc bất cứ thứ gì bạn thấy phù hợp. @localghosts: cảm ơn bạn đã cung cấp thông tin.
dnolan

36

Dưới đây là một số giải thích rõ ràng về sự cố tiền tố sp_ trong SQL Server.

Các thủ tục lưu trữ được đặt tên với tiền tố sp_ là các mầm hệ thống được lưu trữ trong cơ sở dữ liệu Chính.

Nếu bạn cung cấp cho bạn tiền tố này, SQL Server sẽ tìm kiếm chúng trong cơ sở dữ liệu Chính trước, sau đó là cơ sở dữ liệu ngữ cảnh, do đó lãng phí tài nguyên một cách không cần thiết. Và, nếu mầm do người dùng tạo có cùng tên với mầm hệ thống, thì mầm do người dùng tạo sẽ không được thực thi.

Tiền tố sp_ chỉ ra rằng mầm có thể truy cập được từ tất cả các cơ sở dữ liệu, nhưng nó phải được thực thi trong ngữ cảnh của cơ sở dữ liệu hiện tại.

Đây là một lời giải thích thú vị, bao gồm một bản demo của bài hát.

Đây là một nguồn hữu ích khác do Ant cung cấp trong một bình luận.


Hmm, tôi không hiểu. Tại sao sp lại cho hiệu suất ăn khách? Usp hay gsp ổn chứ?
Erwin Rooijakkers

1
@ user2609980 DOK cho biết SQL Server tìm kiếm sp_proc có tiền tố trong Master DB trước, sau đó trong DB hiện tại nếu không tìm thấy
GôTô

+1 để nêu rõ điều gì đó có nhiều giải thích phức tạp ở những nơi khác. Không phải là tin tức đối với tôi, nhưng tôi nghĩ đây là lời giải thích đơn giản và ngắn gọn cho một người mới bắt đầu.
undrline

Liên kết đến bản demo của hit hiệu suất là từ một bài báo được viết vào năm 2001. Nó đã được thay đổi kể từ đó, đây là một bài viết kỹ hơn (từ 2012) của Aaron Bertrand: sqlperformance.com/2012/10/t-sql-queries/sp_prefix
Michael J Swart

16

Hệ thống tiếng Hungary (như tiền tố "usp" ở trên) khiến tôi rùng mình.

Chúng tôi chia sẻ nhiều thủ tục được lưu trữ trên các cơ sở dữ liệu khác nhau, có cấu trúc tương tự, vì vậy đối với các cơ sở dữ liệu cụ thể, chúng tôi sử dụng tiền tố của chính tên cơ sở dữ liệu đó; thủ tục được chia sẻ không có tiền tố. Tôi cho rằng việc sử dụng các lược đồ khác nhau có thể là một giải pháp thay thế để loại bỏ hoàn toàn các tiền tố hơi xấu xí như vậy.

Tên thực tế sau tiền tố hầu như không khác với đặt tên hàm: thường là một động từ như "Thêm", "Đặt", "Tạo", "Tính", "Xóa", v.v., theo sau là một số danh từ cụ thể hơn như "Người dùng "," Doanh thu hàng ngày ", v.v.

Trả lời bình luận của Ant:

  1. Sự khác biệt giữa bảng và dạng xem có liên quan đến những người thiết kế lược đồ cơ sở dữ liệu, không phải những người truy cập hoặc sửa đổi nội dung của nó. Trong trường hợp hiếm hoi cần thông tin chi tiết về lược đồ, bạn có thể dễ dàng tìm thấy. Đối với truy vấn SELECT thông thường, nó không liên quan. Trên thực tế, tôi coi việc có thể coi các bảng và khung nhìn giống nhau là một lợi thế lớn.
  2. Không giống như các hàm và các thủ tục được lưu trữ, tên của một bảng hoặc dạng xem không có khả năng bắt đầu bằng một động từ, hoặc là bất cứ điều gì ngoài một hoặc nhiều danh từ.
  3. Một hàm yêu cầu tiền tố lược đồ được gọi. Trên thực tế, cú pháp cuộc gọi (mà chúng tôi sử dụng, dù sao) rất khác nhau giữa một hàm và một thủ tục được lưu trữ. Nhưng ngay cả khi nó không, thì điều tương tự như 1. sẽ áp dụng: nếu tôi có thể xử lý các hàm và các thủ tục được lưu trữ giống nhau, tại sao tôi lại không?

1
Vì vậy, làm thế nào để bạn biết liệu bạn đang tương tác với một thủ tục, một hàm, một dạng xem, một bảng hay bất cứ thứ gì khác?
Ant

1
Tôi sẽ tưởng tượng rằng các hàm có thể bắt đầu bằng "Get" hoặc là một tên không bắt đầu bằng động từ. Mọi thứ khác sẽ là một thủ tục bởi vì xét cho cùng, chúng được gọi là thủ tục được lưu trữ. Thủ tục ẩn các chi tiết cụ thể như khung nhìn, bảng và bất kỳ thứ gì khác.
Đánh dấu cổ phiếu

3
Nhưng nó không phải là tiếng Hungary. "Usp" không phải là một khai báo biến Hungary. "U" không có nghĩa là "cập nhật", nó là viết tắt của "người dùng", như trong "thủ tục được lưu trữ do người dùng xác định" và nó chỉ đơn thuần bảo vệ khỏi SQL Server đang tìm kiếm trong Master DB mỗi khi nó tìm kiếm thủ tục được lưu trữ của bạn. Đương nhiên, có những cách khác, nhưng "usp" thường được coi là một tiêu chuẩn rộng rãi trong nhiều quân đoàn, và từ những gì tôi thấy nó hoạt động tốt. Nó cũng được giảng dạy bởi Microsoft và quy ước đặt tên do Microsoft đề xuất: msdn.microsoft.com/en-us/library/ms124456(v=SQL.100).aspx
asus3000 Ngày

10

Tôi đã sử dụng khá nhiều tất cả các hệ thống khác nhau trong nhiều năm. Cuối cùng tôi đã phát triển cái này, cái mà tôi tiếp tục sử dụng ngày hôm nay:

Tiếp đầu ngữ :

  • gen - Chung: CRUD, chủ yếu là
  • rpt - Báo cáo: tự giải thích
  • tsk - Tác vụ: thường là một cái gì đó với logic thủ tục, chạy qua các công việc đã lên lịch

Công cụ chỉ định hành động:

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

(Trong trường hợp thủ tục thực hiện nhiều việc, mục tiêu tổng thể được sử dụng để chọn công cụ chỉ định hành động. Ví dụ: INSERT của khách hàng có thể yêu cầu rất nhiều công việc chuẩn bị, nhưng mục tiêu tổng thể là INSERT, vì vậy "Ins" được chọn.

Vật:

Đối với gen (CRUD), đây là tên bảng hoặc chế độ xem đang bị ảnh hưởng. Đối với rpt (Báo cáo), đây là phần mô tả ngắn của báo cáo. Đối với tsk (Nhiệm vụ), đây là mô tả ngắn của nhiệm vụ.

Bộ làm rõ tùy chọn:

Đây là các bit thông tin tùy chọn được sử dụng để nâng cao hiểu biết về quy trình. Ví dụ bao gồm "Bởi", "Cho", v.v.

Định dạng:

[Tiền tố] [Công cụ chỉ định hành động] [Thực thể] [Bộ làm rõ tùy chọn]

Ví dụ về tên thủ tục:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

4
Bây giờ, có một điều thú vị về tiền tố. Đó có vẻ như là một cách tốt để tách mầm theo cách sử dụng của chúng.
DOK

10

TableName_WhatItDoes

  • Comment_GetByID

  • Danh sách khách hàng

  • UserPreference_DeleteByUserID

Không có tiền tố hoặc những điều vô nghĩa ngớ ngẩn của Hungary. Chỉ tên của bảng mà nó có liên quan chặt chẽ nhất và mô tả nhanh về chức năng của nó.

Một lưu ý ở trên: Cá nhân tôi luôn đặt tiền tố cho tất cả CRUD tự động tạo của mình bằng zCRUD_ để nó được xếp vào cuối danh sách mà tôi không cần phải nhìn vào nó.


Tách biệt các mục "z" với phần còn lại nghe có vẻ là một ý tưởng tuyệt vời.
DOK

Tôi thích phương pháp này. Chúng cần phải dễ tìm. Khi tôi xem qua danh sách các động từ mọc đầu tiên và thấy 200 Gets, 200 Ins insert, 200 update, thật khó để tìm tất cả những cái cho một bảng hoặc nhóm cụ thể. Tôi đã sử dụng phương thức động từ đầu tiên, và nó sẽ trở nên lộn xộn nhanh chóng. Tên bảng giải quyết vấn đề này đầu tiên. Vì vậy, ví dụ ở trên trong câu trả lời, tất cả các Bình luận hoặc Khách hàng của bạn sẽ được nhóm lại với nhau, dễ tìm.
chiêm tinh

1
Và điều gì sẽ xảy ra nếu bạn có một truy vấn nối nhiều bảng?
leandronn

10

Bắt đầu một tên thủ tục được lưu trữ với sp_là không hợp lệ trong SQL Server vì hệ thống bắt đầu bằng sp_. Đặt tên nhất quán (ngay cả trong phạm vi hobgoblin-dom) rất hữu ích vì nó hỗ trợ các tác vụ tự động dựa trên từ điển dữ liệu. Tiền tố hơi ít hữu ích hơn trong SQL Server 2005 vì nó hỗ trợ các lược đồ, có thể được sử dụng cho nhiều loại không gian tên khác nhau theo cách mà tiền tố trên tên đã từng sử dụng. Ví dụ, trên một giản đồ hình sao, người ta có thể có các lược đồ mờthực và tham chiếu đến các bảng theo quy ước này.

Đối với các thủ tục được lưu trữ, tiền tố hữu ích cho mục đích xác định các mầm ứng dụng từ các mầm hệ thống. up_so với sp_giúp dễ dàng xác định các thủ tục được lưu trữ ngoài hệ thống từ từ điển dữ liệu.


2
Đặt tên cho những cái tên "sp_" cũng là một ý kiến ​​thực sự tồi về tốc độ, bởi vì SQL Server cố gắng tối ưu hóa các tra cứu của nó cho những thứ dựa trên giả định rằng chúng là các thủ tục hệ thống. Hãy xem ở đây, điểm thứ 5: rakph.wordpress.com/2008/04/19/tips-store-procedure
Ant

4

Tôi luôn đóng gói các thủ tục được lưu trữ trong các gói (tôi đang sử dụng Oracle, tại nơi làm việc). Điều đó sẽ làm giảm số lượng các đối tượng riêng biệt và giúp mã tái sử dụng.

Quy ước đặt tên là một vấn đề của sở thích và một cái gì đó bạn nên đồng ý với tất cả các nhà phát triển khác khi bắt đầu dự án.


Các gói là tốt. Bắt đầu với SQL Server 2005, Management Studio cho phép tạo "giải pháp" để lưu trữ các mầm có liên quan và các câu lệnh SQL khác.
DOK

2
@DOK - lưu ý rằng các gói này không có dấu chân trong chính cơ sở dữ liệu. Chúng hoàn toàn là hiện vật của công cụ front-end. Bạn không thể truy vấn theo gói trong từ điển dữ liệu. Các gói Oracle là các đối tượng lớp đầu tiên trong từ điển dữ liệu hệ thống và có phạm vi riêng của chúng.
ConcernedOfTunbridgeWells

4

đối với cơ sở dữ liệu nhỏ, tôi sử dụng uspTableNameOperationName, ví dụ: uspCustomerCreate, uspCustomerDelete, v.v. Điều này tạo điều kiện cho việc nhóm theo thực thể 'chính'.

đối với cơ sở dữ liệu lớn hơn, hãy thêm lược đồ hoặc tên hệ thống con, ví dụ: Nhận, Mua, v.v. để giữ chúng được nhóm lại với nhau (vì máy chủ sql thích hiển thị chúng theo thứ tự bảng chữ cái)

tôi cố gắng tránh viết tắt trong tên, để rõ ràng (và những người mới tham gia dự án không cần phải thắc mắc 'UNAICFE' là viết tắt của gì vì mầm có tên là uspUsingNoAbbreviationsIncreasesClarityForEveryone)


Vâng, đặc biệt cảm ơn vì đã giải quyết các chữ viết tắt.
DOK

@ [DOK]: bạn được chào đón - sao, không ủng hộ? ;-)
Steven A. Lowe

Steve, bạn có một phiếu ủng hộ. Tôi quá bận rộn để đọc hàng loạt câu trả lời và bình luận, và đau đầu không biết câu trả lời nào là "tốt nhất".
DOK

@ [DOK]: cảm ơn; câu trả lời 'tốt nhất' có lẽ là sự kết hợp phù hợp với tình huống của bạn.
Steven A. Lowe

4

Tôi hiện đang sử dụng một định dạng giống như sau

Kí hiệu:

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

Thí dụ:

P_CMS_USER_UserInfoGet

Tôi thích ký hiệu này vì một vài lý do:

  • bắt đầu với Tiền tố rất đơn giản cho phép mã được viết để chỉ thực thi các đối tượng đi kèm với tiền tố (ví dụ: để giảm việc đưa vào SQL)
  • trong môi trường lớn hơn của chúng tôi, nhiều nhóm đang làm việc trên các ứng dụng khác nhau chạy trên cùng một kiến ​​trúc cơ sở dữ liệu. Ký hiệu Ứng dụng chỉ định nhóm nào sở hữu SP.
  • Phần Mô-đun và Tên chỉ đơn giản là hoàn thành hệ thống thứ bậc. Tất cả các tên phải có thể được đối sánh với Nhóm / Ứng dụng, Mô-đun, Chức năng từ hệ thống.

2

Tôi luôn sử dụng:

usp [Tên bảng] [Hành động] [Chi tiết bổ sung]

Đưa ra một bảng có tên "tblUser", cho tôi:

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

Các thủ tục được sắp xếp theo thứ tự bảng chữ cái theo tên bảng và theo chức năng, vì vậy, thật dễ dàng để xem tôi có thể làm gì với bất kỳ bảng nào. Sử dụng tiền tố "usp" cho tôi biết tôi đang gọi gì nếu tôi (ví dụ) đang viết một thủ tục 1000 dòng tương tác với các thủ tục khác, nhiều bảng, hàm, dạng xem và máy chủ.

Cho đến khi trình soạn thảo trong SQL Server IDE tốt như Visual Studio, tôi vẫn giữ các tiền tố.


2

tiền tố ứng dụng_ tiền tố hoạt động_ mô tả của các đối tượng cơ sở dữ liệu có liên quan (trừ khoảng cách giữa các dấu gạch dưới - phải đặt khoảng trắng để chúng xuất hiện) .

tiền tố hoạt động chúng tôi sử dụng -

  • Get ” - trả về một tập bản ghi
  • ins " - chèn dữ liệu
  • Upd ” - cập nhật dữ liệu
  • Del ” - xóa dữ liệu

ví dụ

wmt_ ins _ customer _details

"công cụ quản lý lực lượng lao động, chèn chi tiết vào bảng khách hàng"

lợi thế

Tất cả các thủ tục được lưu trữ liên quan đến cùng một ứng dụng được nhóm lại với nhau theo tên. Trong nhóm, các thủ tục được lưu trữ thực hiện cùng một loại hoạt động (ví dụ: chèn, cập nhật, v.v.) được nhóm lại với nhau.

Hệ thống này hoạt động tốt cho chúng tôi, có khoảng. 1000 thủ tục được lưu trữ trong một cơ sở dữ liệu ngoài đầu tôi.

Cho đến nay vẫn chưa gặp bất kỳ nhược điểm nào đối với cách tiếp cận này.


Tôi thường ghét việc sử dụng dấu gạch dưới, nhưng cách bạn sử dụng nó - không chỉ để tách biệt tiền tố mà còn để tách biệt hoạt động - sẽ giúp bạn dễ dàng tìm thấy hơn khi quét danh sách hàng trăm mầm. Pretty_neat_idea.
DOK

2

GetXXX - Nhận XXX dựa trên @ID

GetAllXXX - Nhận tất cả XXX

PutXXX - Chèn XXX nếu truyền @ID là -1; cập nhật khác

DelXXX - Xóa XXX dựa trên @ID


1

Tôi nghĩ rằng quy ước đặt tên usp_ không có gì tốt cả.

Trước đây, tôi đã sử dụng các tiền tố Get / Update / Insert / Delete cho các hoạt động CRUD, nhưng bây giờ vì tôi sử dụng Linq to SQL hoặc EF để thực hiện hầu hết các công việc CRUD của mình, những tiền tố này hoàn toàn không còn nữa. Vì tôi có rất ít procs được lưu trữ trong các ứng dụng mới của mình, nên các quy ước đặt tên không còn quan trọng như trước nữa ;-)


1
Tiền tố mỗi mầm bằng _usp không giúp phân biệt giữa chúng. Tôi nghĩ rằng một số DBA giống như tiền tố đó vì nó chỉ ra loại đối tượng cơ sở dữ liệu. Có lẽ chúng tôi sẽ nghe từ một trong số họ thích nó.
DOK

1

Đối với ứng dụng hiện tại mà tôi đang làm việc, chúng tôi có một tiền tố xác định tên ứng dụng (bốn chữ cái viết thường). Lý do cho điều này là ứng dụng của chúng ta phải có thể cùng tồn tại với một ứng dụng kế thừa trong cùng một cơ sở dữ liệu, vì vậy tiền tố là bắt buộc.

Nếu chúng tôi không có ràng buộc kế thừa, tôi khá chắc chắn rằng chúng tôi sẽ không sử dụng tiền tố.

Sau tiền tố, chúng ta thường bắt đầu tên SP bằng một động từ mô tả những gì thủ tục thực hiện và sau đó là tên của thực thể mà chúng ta hoạt động trên đó. Cho phép đa dạng hóa tên thực thể - Chúng tôi cố gắng nhấn mạnh tính dễ đọc, để rõ ràng quy trình thực hiện những gì chỉ từ tên.

Tên thủ tục được lưu trữ điển hình trong nhóm của chúng tôi sẽ là:

shopGetCategories
shopUpdateItem

Chà, bạn không bao giờ biết được, khi bạn đang làm việc trên cơ sở dữ liệu dành riêng cho một ứng dụng, liệu có ứng dụng khác sau này sử dụng cùng cơ sở dữ liệu hay không. Trong tình huống của bạn, nó chắc chắn sẽ giúp tách các mầm.
DOK

1

Tôi không nghĩ tiền tố của bạn thực sự quan trọng, miễn là bạn logic và nhất quán. Cá nhân tôi sử dụng

spu_ [mô tả hành động] [mô tả quy trình]

trong đó mô tả hành động là một trong một loạt các hành động điển hình như lấy, đặt, lưu trữ, chèn, xóa, v.v. Mô tả quy trình là một cái gì đó ngắn gọn nhưng mang tính mô tả, chẳng hạn

spu_archiveCollectionData 

hoặc là

spu_setAwardStatus

Tôi đặt tên các hàm của mình tương tự, nhưng tiền tố bằng udf_

Tôi đã thấy mọi người cố gắng sử dụng ký hiệu giả Hungary để đặt tên thủ tục, theo ý kiến ​​của tôi, điều này che giấu nhiều hơn những gì nó tiết lộ. Vì vậy, miễn là khi tôi liệt kê các thủ tục của mình theo thứ tự bảng chữ cái, tôi có thể thấy chúng được nhóm theo chức năng thì đối với tôi đó dường như là điểm hợp lý giữa trật tự và sự nghiêm ngặt không cần thiết


spu_, thú vị. Khắc phục sự cố sp_ SQL Server.
DOK

1

Tránh sp_ * trong máy chủ SQl vì tất cả các yêu cầu hệ thống được lưu trữ bắt đầu bằng sp_ và do đó hệ thống sẽ khó tìm thấy đối tượng tương ứng với tên hơn.

Vì vậy, nếu bạn bắt đầu với một thứ khác ngoài sp_ thì mọi thứ sẽ trở nên dễ dàng hơn.

Vì vậy, chúng tôi sử dụng một tên phổ biến của Proc_ để bắt đầu. Điều đó làm cho việc xác định các thủ tục dễ dàng hơn nếu được trình bày bằng một tệp lược đồ lớn.

Ngoài ra, chúng tôi chỉ định một tiền tố xác định chức năng. Giống

Proc_Poll_Interface, Proc_Inv_Interface Vân vân.

Điều này cho phép chúng tôi tìm tất cả các tài liệu được lưu trữ thực hiện công việc của POLL so với Kiểm kê, v.v.

Nhưng dù sao thì hệ thống tiền tố phụ thuộc vào miền sự cố của bạn. Nhưng al đã nói và làm điều gì đó tương tự nên có mặt ngay cả khi nó chỉ là để cho phép mọi người xác định vị trí nhanh chóng thủ tục được lưu trữ trong trình đơn thả xuống explorere để chỉnh sửa.

ví dụ khác của chức năng.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

Chúng tôi đã làm theo cách đặt tên dựa trên chức năng coz Procs tương tự như mã / chức năng hơn là các đối tượng tĩnh như bảng. Nó không hữu ích khi Procs có thể hoạt động với nhiều hơn một bảng.

Nếu proc thực hiện nhiều chức năng hơn mức có thể được xử lý trong một tên duy nhất, điều đó có nghĩa là proc của bạn đang làm nhiều hơn mức cần thiết và đã đến lúc phải chia chúng lại.

Hy vọng rằng sẽ giúp.


1

Tôi đã tham gia chuỗi muộn nhưng tôi muốn nhập câu trả lời của mình ở đây:

Trong hai dự án cuối cùng của tôi, có những xu hướng khác nhau như, trong một dự án mà chúng tôi đã sử dụng:

Để lấy dữ liệu: s <tên bảng> _G
Để xóa dữ liệu: s <tên bảng> _D
Để chèn dữ liệu: s <tên bảng> _I
Để cập nhật dữ liệu: s <tên bảng> _U

Quy ước đặt tên này cũng được tuân theo trong front-end bằng cách thêm tiền tố từ dt .

Thí dụ:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

Với sự trợ giúp của các quy ước đặt tên ở trên trong ứng dụng của chúng tôi, chúng tôi có một cái tên hay và dễ nhớ.

Trong dự án thứ hai, chúng tôi sử dụng các quy ước đặt tên giống nhau với sự khác biệt về lill:

Để lấy Dữ liệu: sp_ <tablename> G
Để xóa Dữ liệu: sp_ <tablename> D
Để chèn Dữ liệu: sp_ <tablename> I
Để cập nhật Dữ liệu: sp_ <tablename> U

Thí dụ:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

Hấp dẫn. Tôi chưa bao giờ thấy nó được thực hiện theo cách này, nhưng rất dễ nhớ hoặc đoán tên chính xác.
DOK

1
Cảm ơn DOK, Có, nó dễ dàng để nhớ và chúng tôi phát triển cảm giác miễn phí từ bất kỳ phức tạp trong tên
Gaurav Aroraa

9
Tại sao không _C _R _U _D?
ngày

@onedaywhen - đó là một ý tưởng hay, tôi sẽ đề xuất với DBA của chúng tôi như vậy, chúng tôi có thể duy trì các chuyển đổi đặt tên cho phù hợp. Nhưng, động lực chính để quy ước đặt tên này để trình bày tất cả các đối tượng một cách chính xác, trừ khi tôi bỏ lỡ bất cứ điều gì ...
Gaurav Aroraa

1
tiền tố "sp_" không được khuyến khích.
Piyey
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.