저장 프로 시저에 대한 명명 규칙은 무엇입니까? [닫은]

저장 프로 시저 이름 지정에 대한 다양한 규칙을 보았습니다.

어떤 사람들은 sproc 이름 앞에 usp_를 붙이고, 다른 사람들은 앱 이름의 약어를 붙이고, 또 다른 사람들은 소유자 이름을 붙입니다. 정말로 뜻하지 않는 한 SQL Server에서 sp_를 사용해서는 안됩니다.

일부는 동사 (Get, Add, Save, Remove)로 proc 이름을 시작합니다. 다른 사람들은 엔티티 이름을 강조합니다.

수백 개의 sproc이있는 데이터베이스에서는 이미 존재한다고 생각할 때 스크롤하여 적합한 sproc을 찾는 것이 매우 어려울 수 있습니다. 명명 규칙을 사용하면 sproc을 더 쉽게 찾을 수 있습니다.

명명 규칙을 사용합니까? 그것을 설명하고 다른 선택보다 선호하는 이유를 설명하십시오.

답변 요약 :

• 모든 사람이 특정 명명 규칙을 사용하는 것보다 동일한 명명 규칙을 사용하는 것이 더 중요 할 수 있으므로 명명의 일관성을 옹호하는 것 같습니다.
• 접두사 : 많은 사람들이 usp_ 또는 유사한 것을 사용하지만 (드물게는 sp_) 다른 많은 사람들이 데이터베이스 또는 앱 이름을 사용합니다. 한 영리한 DBA는 gen, rpt 및 tsk를 사용하여 일반적인 CRUD sproc을보고 또는 작업에 사용되는 것과 구별합니다.
• 동사 + 명사는 명사 + 동사보다 약간 더 인기가있는 것 같습니다. 어떤 사람들은 동사에 SQL 키워드 (Select, Insert, Update, Delete)를 사용하는 반면 다른 사람들은 Get 및 Add와 같은 비 SQL 동사 (또는 약어)를 사용합니다. 일부는 단일 명사와 복수 명사를 구별하여 하나 또는 여러 레코드가 검색되는지 여부를 나타냅니다.
• 적절한 경우 끝에 추가 문구가 제안됩니다. GetCustomerById, GetCustomerBySaleDate.
• 어떤 사람들은 이름 세그먼트 사이에 밑줄을 사용하고 어떤 사람들은 밑줄을 피합니다. app_ Get_Customer 대 appGetCustomer-가독성의 문제라고 생각합니다.
• 대규모 sproc 컬렉션은 Oracle 패키지 또는 Management Studio (SQL Server) 솔루션 및 프로젝트 또는 SQL Server 스키마로 분리 될 수 있습니다.
• 알 수없는 약어는 피해야합니다.

내가 한 답을 선택한 이유 : 좋은 응답이 너무 많습니다. 다들 감사 해요! 보시다시피 하나만 선택하는 것은 매우 어려울 것입니다. 내가 선택한 사람이 저에게 반향을 일으켰습니다. 나는 그가 설명하는 것과 동일한 경로를 따랐습니다. Verb + Noun을 사용하려고 시도했지만 고객에게 적용되는 모든 sproc을 찾을 수 없었습니다.

기존의 sproc을 찾거나 존재하는지 확인하는 것은 매우 중요합니다. 누군가 실수로 다른 이름으로 중복 된 sproc을 만들면 심각한 문제가 발생할 수 있습니다.

일반적으로 수백 개의 sproc이있는 매우 큰 앱에서 작업하기 때문에 찾기 쉬운 이름 지정 방법을 선호합니다. 작은 앱의 경우 메서드 이름에 대한 일반적인 코딩 규칙을 따르므로 Verb + Noun을 옹호 할 수 있습니다.

그는 또한 유용하지 않은 usp_ 대신 앱 이름 접두사를 옹호합니다. 여러 사람이 지적했듯이 데이터베이스에는 여러 앱에 대한 sproc이 포함되는 경우가 있습니다. 따라서 앱 이름을 접두사로 지정하면 sproc을 분리하는 데 도움이되고 DBA와 다른 사용자가 sproc이 사용되는 앱을 결정하는 데 도움이됩니다.

마지막 프로젝트에서는 usp_ [Action] [Object] [Process]를 사용했습니다. 예를 들어 usp_AddProduct 또는 usp_GetProductList, usp_GetProductDetail입니다. 그러나 이제 데이터베이스는 700 개 이상의 프로 시저에 있으며 특정 개체에서 모든 프로 시저를 찾기가 훨씬 더 어려워집니다. 예를 들어 이제 제품 추가에 대해 50 개의 홀수 추가 프로 시저를 검색하고 가져 오기 등에 대해 50 개의 홀수를 검색해야합니다.

이 때문에 새 응용 프로그램에서 프로 시저 이름을 개체별로 그룹화 할 계획이므로 절차 이름에서 공제 할 수있는 절차를 알려주는 것 외에 다소 중복 된 것으로 느껴지므로 usp도 삭제합니다. 절차 자체.

새로운 형식은 다음과 같습니다.

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

특히 많은 양의 sproc이있는 경우 나중에 쉽게 찾을 수 있도록 항목을 그룹화하는 데 도움이됩니다.

둘 이상의 개체가 사용되는 위치와 관련하여 대부분의 인스턴스에는 기본 개체와 보조 개체가 있으므로 기본 개체는 일반 인스턴스에서 사용되고 보조 개체는 프로세스 섹션에서 참조됩니다 (예 : App_Product_AddAttribute).

다음은 SQL Server의 sp_ 접두사 문제에 대한 설명입니다.

sp_ 접두사로 명명 된 저장 프로시 저는 Master 데이터베이스에 저장된 시스템 sproc입니다.

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 (작업)의 경우 작업에 대한 간단한 설명입니다.

선택적인 Clarifier :

절차에 대한 이해를 높이기 위해 사용되는 선택적 정보 비트입니다. 예를 들면 "By", "For"등이 있습니다.

체재:

[접두어] [액션 지정자] [엔티티] [선택적 명확성]

프로 시저 이름의 예 :

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

TableName_WhatItDoes

• Comment_GetByID

• 고객 _ 목록

• UserPreference_DeleteByUserID

접두사 나 어리석은 헝가리어 말도 안되는 말도 없습니다. 가장 밀접하게 관련된 테이블의 이름과 그 기능에 대한 간단한 설명입니다.

위의 한 가지주의 사항 : 개인적으로 자동 생성 된 모든 CRUD 앞에 zCRUD_ 접두사를 붙여서 볼 필요가없는 목록의 끝으로 정렬됩니다.

sp_시스템 sproc이 모두 sp_로 시작하기 때문에 SQL Server에서 저장 프로 시저 이름을 시작하는 것은 좋지 않습니다. 일관된 이름 지정 (hobgoblin-dom 정도까지)은 데이터 사전을 기반으로 자동화 된 작업을 용이하게하기 때문에 유용합니다. 접두사는 이름의 접두사가 사용되는 방식으로 다양한 유형의 네임 스페이스에 사용할 수있는 스키마를 지원하기 때문에 SQL Server 2005에서 약간 덜 유용합니다. 예를 들어, 스타 스키마에서 dim 및 fact 스키마를 가질 수 있으며이 규칙에 따라 테이블을 참조 할 수 있습니다.

저장 프로 시저의 경우 접두사는 시스템 sproc에서 응용 프로그램 sproc을 식별하는 데 유용합니다. up_vs. sp_는 데이터 사전에서 비 시스템 저장 프로 시저를 비교적 쉽게 식별 할 수 있도록합니다.

저는 항상 저장 프로 시저를 패키지로 캡슐화 합니다 (직장에서 Oracle을 사용하고 있습니다). 이렇게하면 개별 개체의 수가 줄어들고 코드 재사용에 도움이됩니다.

명명 규칙은 취향의 문제이며 프로젝트 시작시 다른 모든 개발자와 동의해야합니다.

작은 데이터베이스의 경우 uspTableNameOperationName (예 : uspCustomerCreate, uspCustomerDelete 등)을 사용합니다. 이렇게하면 '주'엔티티별로 그룹화가 용이 해집니다.

큰 데이터베이스의 경우 스키마 또는 하위 시스템 이름 (예 : Receiving, Purchasing 등)을 추가하여 그룹화를 유지합니다 (SQL 서버는 알파벳순으로 표시하는 것을 좋아하기 때문에).

명확성을 위해 이름에 약어를 사용하지 않으려 고합니다 (프로젝트의 새로운 사람들은 sproc의 이름이 uspUsingNoAbbreviationsIncreasesClarityForEveryone이기 때문에 'UNAICFE'가 무엇을 의미하는지 궁금해 할 필요가 없습니다)

현재 다음과 같은 형식을 사용하고 있습니다.

표기법:

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

예:

P_CMS_USER_UserInfoGet

나는 몇 가지 이유로이 표기법을 좋아합니다.

• 매우 간단한 접두사로 시작하면 접두사로 시작하는 객체 만 실행하도록 코드를 작성할 수 있습니다 (예 : SQL 주입 감소).
• 대규모 환경에서는 여러 팀이 동일한 데이터베이스 아키텍처를 실행하는 서로 다른 앱을 작업하고 있습니다. 응용 프로그램 표기법은 SP를 소유하는 그룹을 지정합니다.
• 모듈 및 이름 섹션은 단순히 계층 구조를 완성합니다. 모든 이름은 계층 구조에서 그룹 / 앱, 모듈, 함수와 일치 할 수 있어야합니다.

나는 항상 다음을 사용합니다.

usp [테이블 이름] [작업] [추가 세부 정보]

"tblUser"라는 테이블이 주어지면 다음을 제공합니다.

• uspUserCreate
• uspUserSelect
• uspUserSelectByNetworkID

절차는 테이블 이름 및 기능별로 알파벳순으로 정렬되어 있으므로 주어진 테이블에 대해 수행 할 수있는 작업을 쉽게 확인할 수 있습니다. 접두사 "usp"를 사용하면 다른 프로 시저, 여러 테이블, 함수, 뷰 및 서버와 상호 작용하는 1000 줄 프로 시저를 작성하는 경우 (예를 들어) 호출하는 내용을 알 수 있습니다.

SQL Server IDE의 편집기가 Visual Studio만큼 좋을 때까지 접두사를 유지합니다.

응용 프로그램 접두사 _ 작업 접두사 _ 관련된 데이터베이스 개체에 대한 설명 (밑줄 사이의 공백 빼기-표시하려면 공백을 넣어야 함) .

우리가 사용하는 연산 접두사-

• " get "– 레코드 세트를 반환합니다.
• “ ins ”– 데이터 삽입
• “ upd ”– 데이터 업데이트
• “ del ”– 데이터 삭제

예 :

wmt_ ins _ customer _details

"인력 관리 도구, 고객 테이블에 세부 정보 삽입"

장점

동일한 애플리케이션과 관련된 모든 저장 프로시 저는 이름별로 그룹화됩니다. 그룹 내에서 동일한 종류의 작업 (예 : 삽입, 업데이트 등)을 수행하는 저장 프로 시저가 함께 그룹화됩니다.

이 시스템은 우리에게 잘 작동합니다. 내 머리 꼭대기에서 하나의 데이터베이스에 1000 개의 저장 프로 시저가 있습니다.

지금까지이 접근 방식에 어떤 단점도 발견하지 못했습니다.

GetXXX-@ID를 기준으로 XXX 가져 오기

GetAllXXX-모든 XXX 가져 오기

PutXXX-전달 된 @ID가 -1이면 XXX를 삽입합니다. 다른 업데이트

DelXXX-@ID를 기반으로 XXX 삭제

usp_ 명명 규칙은 아무 소용이 없다고 생각합니다.

과거에는 CRUD 작업에 Get / Update / Insert / Delete 접두사를 사용했지만 이제는 Linq to SQL 또는 EF를 사용하여 대부분의 CRUD 작업을 수행하므로 완전히 사라졌습니다. 새 응용 프로그램에 저장된 proc가 너무 적기 때문에 명명 규칙은 더 이상 이전처럼 중요하지 않습니다 ;-)

현재 작업중인 응용 프로그램의 경우 응용 프로그램 이름을 식별하는 접두사 (4 개의 소문자)가 있습니다. 그 이유는 응용 프로그램이 동일한 데이터베이스에서 레거시 응용 프로그램과 공존 할 수 있어야하므로 접두사가 필수입니다.

레거시 제약이 없었다면 접두사를 사용하지 않을 것이라고 확신합니다.

접두사 뒤에는 일반적으로 프로 시저가 수행하는 작업을 설명하는 동사로 SP 이름을 시작한 다음 작업을 수행하는 엔터티의 이름을 사용합니다. 엔티티 이름의 복수화 허용-이름만으로 절차가 수행하는 작업을 명확하게하기 위해 가독성을 강조하려고합니다.

우리 팀의 일반적인 저장 프로 시저 이름은 다음과 같습니다.

shopGetCategories
shopUpdateItem

논리적이고 일관성이있는 한 접두사가 무엇인지 정확히 중요하지 않다고 생각합니다. 개인적으로 나는

spu_ [액션 설명] [프로세스 설명]

여기서 작업 설명은 가져 오기, 설정, 보관, 삽입, 삭제 등과 같은 작은 범위의 일반적인 작업 중 하나입니다. 프로세스 설명은 짧지 만 설명적인 것입니다. 예를 들어

spu_archiveCollectionData 

또는

spu_setAwardStatus

내 함수의 이름은 비슷하지만 접두사는 udf_입니다.

나는 사람들이 프로 시저 명명에 의사-헝가리 표기법을 사용하려고 시도하는 것을 보았습니다. 제 생각에는 그것이 드러내는 것보다 더 많은 것을 숨 깁니다. 내 절차를 알파벳순으로 나열 할 때 기능별로 그룹화되어있는 것을 볼 수 있다면 순서와 불필요한 엄격함 사이의 최적 지점 인 것 같습니다.

SQl 서버에서 sp_ *를 사용하지 마십시오. 모든 시스템 저장 절차는 sp_로 시작하므로 시스템이 이름에 해당하는 개체를 찾기가 더 어려워집니다.

따라서 sp_ 이외의 것으로 시작하면 일이 더 쉬워집니다.

그래서 우리는 Proc_의 공통 이름을 사용하여 시작합니다. 이렇게하면 하나의 큰 스키마 파일이있는 경우 프로 시저를 쉽게 식별 할 수 있습니다.

그 외에도 함수를 식별하는 접두사를 할당합니다. 처럼

Proc_Poll_Interface, Proc_Inv_Interface 기타

이를 통해 POLL 작업을 수행하는 저장된 프록과 인벤토리 등을 수행하는 모든 저장된 프록을 찾을 수 있습니다.

어쨌든 접두사 시스템은 문제 도메인에 따라 다릅니다. 그러나 al은 사람들이 편집을 위해 탐색 드롭 다운에서 저장 프로 시저를 신속하게 찾을 수 있도록하더라도 유사한 작업을 수행해야한다고 말했습니다.

다른 예의 기능.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

우리는 함수 기반 이름 지정을 따랐습니다. coz Procs는 테이블과 같은 정적 개체가 아니라 코드 / 함수와 유사합니다. Procs가 둘 이상의 테이블에서 작동하는 것은 도움이되지 않습니다.

프로 시저가 단일 이름으로 처리 할 수있는 것보다 더 많은 기능을 수행했다면 프로 시저가 필요한 것보다 훨씬 많은 기능을 수행하고 있으며이를 다시 분할 할 시간이 있음을 의미합니다.

도움이되기를 바랍니다.

스레드에 늦게 가입했지만 여기에 내 답장을 입력하고 싶습니다.

지난 두 프로젝트에는 다음과 같은 다른 트렌드가 있습니다.

데이터 가져 오기 : s <tablename> _G
데이터 삭제 : s <tablename> _D
데이터 삽입 : s <tablename> _I
데이터 업데이트 : s <tablename> _U

이 명명 규칙은 dt 라는 단어를 접두사로 사용하여 프런트 엔드에서도 따릅니다 .

예:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

응용 프로그램에서 위의 명명 규칙의 도움으로 우리는 좋고 기억하기 쉬운 이름을 갖게됩니다.

두 번째 프로젝트에서 우리는 lill 차이가있는 동일한 명명 규칙을 사용했습니다.

데이터 가져 오기 : sp_ <tablename> G
데이터 삭제 : sp_ <tablename> D
데이터 삽입 : sp_ <tablename> I
데이터 업데이트 : sp_ <tablename> U

예:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU