저장 프로 시저에 대한 명명 규칙은 무엇인가? [닫은]

내가 저장 프로 시저의 이름을 지정하기위한 다양한 규칙을 보았다.

어떤 사람들은 소유자의 이름, usp_와 응용 프로그램 이름의 약어와 다른 사람, 아직도 다른 사람을 sproc에 이름을 접두사. 당신이 정말로 그것을 의미하지 않는 한 당신은 SQL Server의 SP_을 사용할 수 없습니다.

일부는 동사 (가져 오기, 저장, 제거를 추가)로 PROC 이름을 시작합니다. 다른 사람들은 엔티티 이름 (들)을 강조한다.

sprocs가 수백 개의 데이터베이스에, 주위 스크롤 하나가 이미 존재 생각할 때 적절한 SPROC을 찾기 위해 매우 어려울 수 있습니다. 이름 지정 규칙은 쉽게 sproc에 위치를 만들 수 있습니다.

당신은 이름 지정 규칙을 사용하십니까? 그것을 설명, 당신은 다른 선택에 그것을 선호하는 이유를 설명하십시오.

응답의 요약 :

내가했던 답을 선택하는 이유 : 너무 많은 좋은 반응이 있습니다. 모두 감사합니다! 당신이 볼 수 있듯이, 단지 하나를 선택하는 것은 매우 어려울 것이다. 한 나는 저와 공감을 선택했다. 동사 + 명사를 사용하려고하고 고객에 적용되는 sprocs가 모두 찾을 수없는 - 나는 그가 설명 동일한 경로를 따랐다.

기존의 sproc를 찾을 수, 또는 하나라도 있는지 확인할 수 있다는 것은 매우 중요하다. 누군가가 실수로 다른 이름과 중복 sproc에를 생성하면 심각한 문제가 발생할 수 있습니다.

나는 일반적으로 sprocs가 수백 개의 매우 큰 응용 프로그램에서 작동하기 때문에, 나는 가장 찾기 쉬운 이름 지정 방법을 선호합니다. 이 방법은 이름에 대한 일반적인 코딩 규칙을 다음과 같이 작은 응용 프로그램을 위해, 나는, 동사 + 명사를 옹호 수 있습니다.

그는 또한 응용 프로그램 이름 대신에 매우 유용하지 usp_와 접두사를지지한다. 여러 사람이 지적한 바와 같이, 때로는 데이터베이스는 여러 애플 리케이션을위한 sprocs가 포함되어 있습니다. 따라서, 응용 프로그램 이름을 접두어로하면 sprocs가를 분리하는 데 도움이 및 DBA와 다른 사람들이 SPROC를 사용하는 응용 프로그램을 결정하는 데 도움이됩니다.

해결법

==============================
1.내 마지막 프로젝트를 위해 내가 usp_를 사용 [액션] [객체] [프로세스]를 예를 들어, usp_AddProduct 또는 usp_GetProductList, usp_GetProductDetail합니다. 그러나 이제 데이터베이스가 특정 객체에 대한 모든 절차를 찾기 위해 많은 어려워진다, 700 개 절차에 플러스. 예를 들어 내가 지금 가져 오기 등 홀수 50 개 홀수 추가 제품 추가에 대한 절차 및 50을 검색해야

내 마지막 프로젝트를 위해 내가 usp_를 사용 [액션] [객체] [프로세스]를 예를 들어, 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
```
그것은 sprocs가 많은 양의가, 특히 나중에 쉽게 찾기위한 그룹 일에 도움이됩니다.

하나 이상의 개체가 사용되는 경우에 관해서는, 그 대부분의 경우는 주 목적은 정상적인 인스턴스에 이용되도록, 기본 및 보조 오브젝트를 가지며, 보조 예컨대 App_Product_AddAttribute 위해, 처리 섹션에 대해 참조되었습니다.
==============================
2.다음은 SQL Server의 SP_의 접두어 문제에 대한 약간의 설명이다.

다음은 SQL Server의 SP_의 접두어 문제에 대한 약간의 설명이다.

접두사 SP_로 이름이 저장 프로 시저는 마스터 데이터베이스에 저장 시스템 sprocs가 있습니다.

당신이 당신의 sproc에이 접두사를주는 경우에, SQL 서버, 따라서 불필요하게 자원을 낭비하고 상황에 맞는 데이터베이스, 먼저 마스터 데이터베이스에 찾습니다. 사용자가 생성 한 sproc에이 시스템 sproc에 같은 이름을 가진 경우에, 사용자가 만든 sproc에 실행되지 않습니다.

SP_의 접두어는 sproc에 모든 데이터베이스에서 액세스 할 수 있지만 그것이 현재 데이터베이스의 컨텍스트에서 실행되어야한다는 것을 나타냅니다.

여기에 성능 저하의 데모를 포함하는 좋은 설명이 있습니다.

여기에 코멘트에 개미가 제공하는 또 다른 유용한 소스입니다.
==============================
3.시스템 헝가리어 ( "USP"접두사 위의이 같은) 나를 전율한다.

시스템 헝가리어 ( "USP"접두사 위의이 같은) 나를 전율한다.

우리는 그래서 데이터베이스 고유의 것들에 대한, 우리는 데이터베이스 이름 자체의 접두사를 사용, 다른 유사 구조의 데이터베이스에서 많은 저장 프로 시저를 공유; 공유 절차는 접두사가 없습니다. 나는 모두 같은 다소 추한 접두사를 제거 할 수있는 대안이 될 수있는 다른 스키마를 사용하는 가정합니다.

접두사 후 실제 이름은 함수 이름에서 거의 차이가 : 일반적으로, "세트", "생성", "추가"와 같은 동사, "계산"과 같은 "사용자와 같은 몇 가지 더 구체적인 명사 뒤에, 등,"삭제 " ","DailyRevenues ", 등등.

개미의 코멘트에 응답 :
==============================
4.나는 거의 모든 년 동안 서로 다른 시스템의 사용했다. 드디어 오늘 계속 사용이 하나의 개발 :

나는 거의 모든 년 동안 서로 다른 시스템의 사용했다. 드디어 오늘 계속 사용이 하나의 개발 :

접두사 :

액션 지정자 :
```
Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE
```
(절차가 많은 일을 경우, 전체 목표는 예를 들어, 고객 INSERT는 준비 작업의 좋은 거래를 필요로 할 수있다. 작업 지정자를 선택하는 데 사용되지만, 전반적인 목표는 그래서 "INS는"선택, INSERT이다.

목적:

겐 (CRUD) 들어,이 영향을받는 테이블 또는 뷰 이름입니다. RPT (보고서)의 경우,이 보고서의 간단한 설명입니다. 쯧 (작업)의 경우이 작업의 간단한 설명입니다.

옵션 정화기 :

이러한 정보의 선택 비트는 절차의 이해를 증진하는 데 사용됩니다. 예로는 "옵션", "저자"를 포함

체재:

[접두사] 액션 지정자 [법인] [선택 정화기]

프로 시저 이름의 예 :
```
genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection
```
==============================
5.TableName_WhatItDoes

TableName_WhatItDoes

어떤 접두사하거나 바보 헝가리어 넌센스. 그냥이 가장 밀접하게와 연결된 테이블의 이름과 용도에 대한 간단한 설명입니다.

위의 한 가지주의 : zCRUD_와 나는 개인적으로 항상 접두사 내 모든 자동 생성 된 CRUD는 그래서 내가 그것을 볼 필요가 없습니다 목록의 마지막에 정렬있다.
==============================
6.시스템 sprocs가 모든 SP_로 시작하기 때문에 저장 프로 시저의 이름 withsp_를 시작하면 SQL Server의 불량입니다. 이 데이터 사전을 이용한 작업을 자동화 facilititates 때문에 (심지어 먹 깨비-DOM의 정도) 일관된 명명 유용하다. 이 이름에 접두어가 사용하는 방식 네임 스페이스의 여러 유형에 사용할 수있는 스키마를 지원하는 접두사가 약간 SQL Server 2005에서 덜 유용합니다. 예를 들어, 스타 스키마에 하나의 희미한 실제로 스키마를 가질 수 있으며,이 규칙에 의해 표를 참조하십시오.

시스템 sprocs가 모든 SP_로 시작하기 때문에 저장 프로 시저의 이름 withsp_를 시작하면 SQL Server의 불량입니다. 이 데이터 사전을 이용한 작업을 자동화 facilititates 때문에 (심지어 먹 깨비-DOM의 정도) 일관된 명명 유용하다. 이 이름에 접두어가 사용하는 방식 네임 스페이스의 여러 유형에 사용할 수있는 스키마를 지원하는 접두사가 약간 SQL Server 2005에서 덜 유용합니다. 예를 들어, 스타 스키마에 하나의 희미한 실제로 스키마를 가질 수 있으며,이 규칙에 의해 표를 참조하십시오.

저장 프로 시저의 경우, 추가하는 설정은 시스템 sprocs가에서 응용 프로그램의 sprocs가를 indentifying의 목적에 유용합니다. up_ 대 SP_ 비교적 쉽게 데이터 사전에서 비 시스템 저장 프로 시저를 식별 할 수 있습니다.
==============================
7.나는 항상 패키지의 저장 프로 시저 (나는 직장에서, 오라클을 사용하고 있습니다)를 캡슐화합니다. 즉 별도의 객체 및 도움말 코드 재사용의 수를 줄일 수 있습니다.

나는 항상 패키지의 저장 프로 시저 (나는 직장에서, 오라클을 사용하고 있습니다)를 캡슐화합니다. 즉 별도의 객체 및 도움말 코드 재사용의 수를 줄일 수 있습니다.

이름 지정 규칙은 맛과 당신이 프로젝트 시작 전혀 다른 개발자에 동의해야 뭔가의 문제이다.
==============================
8.작은 데이터베이스의 경우, 내가 uspTableNameOperationName를 사용, 예를 들어, uspCustomerCreate, uspCustomerDelete 등 '주요'개체에 의해 그룹화이 용이하게합니다.

작은 데이터베이스의 경우, 내가 uspTableNameOperationName를 사용, 예를 들어, uspCustomerCreate, uspCustomerDelete 등 '주요'개체에 의해 그룹화이 용이하게합니다.

큰 데이터베이스에 대한 스키마 또는 서브 시스템 이름을 추가, 예를 들어, 함께 유지하는 등, 구입 그룹화 받기 (SQL Server가 알파벳순으로 표시하기를 좋아하기 때문에)

나는 ( 'UNAICFE'는 sproc에 이름이 지정되어 있기 때문에 uspUsingNoAbbreviationsIncreasesClarityForEveryone 무엇의 약자인지 궁금하지 않아도 프로젝트에 새로운 사람들) 명확성을 위해 이름에 약어를 피하려고
==============================
9.저는 현재 다음과 같다 형식을 사용

저는 현재 다음과 같다 형식을 사용

표기법:

[PREFIX [APPLICATION] MODULE] _ [NAME]

예:

P_CMS_USER_UserInfoGet

나는 몇 가지 이유에 대해이 표기법을 좋아한다 :
==============================
10.난 항상 사용 :

난 항상 사용 :

USP [테이블 이름] [액션] [추가 상세보기]

저를 준다 "tblUser"라는 테이블을 감안할 때 :

절차는 알파벳 순 그래서 난 어떤 주어진 테이블에 무엇을 할 수 있는지 쉽게, 테이블 이름과 기능으로 분류되어 있습니다. 접두사 "USP"를 사용하여 제가 (예를 들어)이야 만약 내가 1000 줄 절차를 작성 호출하고있는 무슨을 알 수 있습니다 다른 절차, 여러 테이블, 함수, 뷰 및 서버와 상호 작용합니다.

은 SQL Server IDE에서 에디터가 좋은으로 될 때까지 비주얼 스튜디오로 내가 접두사를 유지하고있다.
==============================
11.데이터베이스 응용 프로그램 prefix_ 작업 prefix_ 설명이 포함 된 객체 (마이너스 밑줄 사이의 공간은 - 그들을 표시하기에 공백을 넣어했다).

데이터베이스 응용 프로그램 prefix_ 작업 prefix_ 설명이 포함 된 객체 (마이너스 밑줄 사이의 공간은 - 그들을 표시하기에 공백을 넣어했다).

작업은 우리가 사용하는 접두사 -

예컨대

wmt_ 인 _ 고객 _details

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

장점

동일한 프로그램에 관련된 모든 프로 시저 이름으로 함께 그룹화된다. 그룹 내에서 (예를 들어 인서트가 업데이트 등)을 함께 그룹화 조작 같은 종류의 수행 절차를 저장.

이 시스템은 약 가지고, 우리를 위해 잘 작동합니다. 내 머리 위로 떨어져 하나의 데이터베이스에서 1000 저장 프로 시저.

지금까지이 방법에 불이익 건너하지 않았습니다.
==============================
12.의 getXXX는 - @ID에 따라 XXX를 가져옵니다

의 getXXX는 - @ID에 따라 XXX를 가져옵니다

GetAllXXX - 모든 XXX를 가져옵니다

PutXXX - 삽입 XXX 통과 @ID 인 경우 -1; 다른 업데이트

DelXXX - @ID에 따라 삭제 XXX
==============================
13.나는 usp_ 명명 규칙이 좋은 아무도하지 않는다 생각합니다.

나는 usp_ 명명 규칙이 좋은 아무도하지 않는다 생각합니다.

과거에는, 나는 CRUD 작업에 익숙해 / 업데이트 / 삽입 / 삭제 접두사를했습니다,하지만 난 내 CRUD 작업의 대부분을 수행하는 SQL 또는 EF Linq에를 사용하기 때문에 지금이 완전히 사라 졌어요. 나는 나의 새로운 애플리케이션에 매우 몇 저장 발동을 가지고 있기 때문에, 명명 규칙 더 이상 그들이 사용 문제처럼 ;-)
==============================
14.내가 작업하고있는 현재, 응용 프로그램, 우리는 접두사를 식별하는 응용 프로그램 이름 (사 개 소문자 문자). 그 이유는 접두사가 필수입니다, 그래서 우리의 응용 프로그램이 동일한 데이터베이스에서 기존 응용 프로그램과 공존 할 수 있어야한다는 것입니다.

내가 작업하고있는 현재, 응용 프로그램, 우리는 접두사를 식별하는 응용 프로그램 이름 (사 개 소문자 문자). 그 이유는 접두사가 필수입니다, 그래서 우리의 응용 프로그램이 동일한 데이터베이스에서 기존 응용 프로그램과 공존 할 수 있어야한다는 것입니다.

우리는 기존의 제약 조건을 가지고 있지 않은 경우, 나는 우리가 접두사를 사용하지 않을 것이라고 확신합니다.

접두사 후 우리는 일반적으로 절차가 무엇을 설명하는 동사, 그리고 우리가 운영하는 단체의 이름으로 SP 이름을 시작합니다. 엔티티 이름의 복수화가 허용됩니다 - 우리는 가독성을 강조하려고,이 절차가 혼자 이름에서 무엇을하는지 분명하다 그래서.

우리 팀에 일반적인 저장 프로 시저의 이름은 다음과 같습니다
```
shopGetCategories
shopUpdateItem
```
==============================
15.나는 정말 접두사가 너무 오래 당신이 논리적이고 일관성있는 한 것입니다 정확히 어떤 중요한 생각하지 않습니다. 개인적으로 사용

나는 정말 접두사가 너무 오래 당신이 논리적이고 일관성있는 한 것입니다 정확히 어떤 중요한 생각하지 않습니다. 개인적으로 사용

spu_ [동작 설명] [공정 설명]

작업 설명은 GET, 세트, 보관, 삽입, 삭제 등의 일반적인 행동의 작은 범위 중 하나입니다 프로세스 설명, 예를 들어 뭔가 짧지 만 설명입니다
```
spu_archiveCollectionData 
```
또는
```
spu_setAwardStatus
```
나는 접두사와 udf_ 유사하게 제 기능을 이름을하지만,

나는 사람들이 내 의견 가죽에있는 더는 계시보다 프로 시저 이름에 대한 의사 - 헝가리 표기법을 사용하려고 보았다. 너무 오래 내가 알파벳 순으로 내 절차를 나열 할 때 나는 그들을 위해 불필요한 엄격 사이의 달콤한 자리가 될 것 같다 그 다음 날 위해 기능별로 그룹화 볼 수
==============================
16.모든 시스템 저장 prcedures 사촌 SQL Server의 피 SP_ *은 SP_로 시작하고 따라서 이름에 해당하는 객체를 찾기 위해 더 열심히 시스템에 대한된다.

모든 시스템 저장 prcedures 사촌 SQL Server의 피 SP_ *은 SP_로 시작하고 따라서 이름에 해당하는 객체를 찾기 위해 더 열심히 시스템에 대한된다.

다른 뭔가로 시작한다면 SP_ 일이 쉬워 질보다.

그래서 우리는 시작하는 Proc_의 공통 이름을 사용합니다. 즉 하나 개의 큰 스키마 파일되게 해두면 편리하게 절차를 식별 할 수 있습니다.

그렇다 우리는 함수를 식별 접두사를 할당하는 것이에서. 처럼

Proc_Poll_Interface, Proc_Inv_Interface 등

이것은 즉, 재고 등을 수행 대 우리는 설문 조사의 일을 모두 저장 발동을 찾을 수 있습니다

아무튼 접두사 시스템은 문제 도메인에 따라 달라집니다. 그러나 알 말했다 비슷한 완료 뭔가가 quicly에 사람들이 explorere에서 저장 프로 시저가 편집 드롭 다운 찾을 수 있도록 단지가 될 경우에도 존재해야한다.

다른 예를 들면 기능입니다.
```
Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History
```
우리는 수 프로세서는 코드 / 기능보다는 테이블과 같은 정적 객체에 가깝다 사촌 기능을 기반으로 이름을 따랐다. 이 프로세서 수는 두 개 이상의 테이블을 작동 할 수 있는지 도움을 나던.

proc 디렉토리는 하나의 이름으로 처리 할 수있는 것보다 더 많은 기능을 수행 한 경우, 그것은 당신의 PROC가 다시 분할 훨씬 더 필요하고 그 시간보다 길을 일을 의미합니다.

희망이 도움이.
==============================
17.나는 늦게 스레드에 합류하지만 난 여기에 내 대답을 입력합니다 :

나는 늦게 스레드에 합류하지만 난 여기에 내 대답을 입력합니다 :

하나 우리가 예전처럼 내 마지막 두 개의 프로젝트에서 서로 다른 경향이있다 :

이 명명 규칙은 또한, 단어 접두어 DT하여 프런트 엔드에 따른다.

예:
```
exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U
```
우리의 응용 프로그램에서 위의 명명 규칙의 도움으로 우리는 좋은이 쉬운 이름을 기억 할 수 있습니다.

두 번째 프로젝트에있는 동안 우리는 lill 차이와 같은 명명 규칙을 사용 :

예:
```
exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
```

from https://stackoverflow.com/questions/238267/what-is-your-naming-convention-for-stored-procedures by cc-by-sa and MIT license

'SQL' 카테고리의 다른 글

[SQL] SQL 서버 SELECT INTO의 @variable? (0)	2020.05.30
[SQL] SQL NoSQL의 VS (MySQL의) (CouchDB를) [폐쇄] (0)	2020.05.30
[SQL] SQL 문은 열 유형을 얻을 수 있습니다 (0)	2020.05.30
[SQL] 어떻게 다른 테이블에 가입하지 않는 행을 제외하려면? (0)	2020.05.30
[SQL] 오라클의 뷰 및 구체화 된 뷰의 차이점은 무엇입니까? (0)	2020.05.30

복붙노트

[SQL] 저장 프로 시저에 대한 명명 규칙은 무엇인가? [닫은]

저장 프로 시저에 대한 명명 규칙은 무엇인가? [닫은]

해결법

2.다음은 SQL Server의 SP_의 접두어 문제에 대한 약간의 설명이다.

3.시스템 헝가리어 ( "USP"접두사 위의이 같은) 나를 전율한다.

4.나는 거의 모든 년 동안 서로 다른 시스템의 사용했다. 드디어 오늘 계속 사용이 하나의 개발 :

5.TableName_WhatItDoes

7.나는 항상 패키지의 저장 프로 시저 (나는 직장에서, 오라클을 사용하고 있습니다)를 캡슐화합니다. 즉 별도의 객체 및 도움말 코드 재사용의 수를 줄일 수 있습니다.

8.작은 데이터베이스의 경우, 내가 uspTableNameOperationName를 사용, 예를 들어, uspCustomerCreate, uspCustomerDelete 등 '주요'개체에 의해 그룹화이 용이하게합니다.

9.저는 현재 다음과 같다 형식을 사용

10.난 항상 사용 :

11.데이터베이스 응용 프로그램 prefix_ 작업 prefix_ 설명이 포함 된 객체 (마이너스 밑줄 사이의 공간은 - 그들을 표시하기에 공백을 넣어했다).

12.의 getXXX는 - @ID에 따라 XXX를 가져옵니다

13.나는 usp_ 명명 규칙이 좋은 아무도하지 않는다 생각합니다.

15.나는 정말 접두사가 너무 오래 당신이 논리적이고 일관성있는 한 것입니다 정확히 어떤 중요한 생각하지 않습니다. 개인적으로 사용

16.모든 시스템 저장 prcedures 사촌 SQL Server의 피 SP_ *은 SP_로 시작하고 따라서 이름에 해당하는 객체를 찾기 위해 더 열심히 시스템에 대한된다.

17.나는 늦게 스레드에 합류하지만 난 여기에 내 대답을 입력합니다 :

'SQL' 카테고리의 다른 글

티스토리툴바