문제

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

어떤 사람들은 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 스키마로 분리될 수 있습니다.
  • 이해하기 어려운 약어는 피해야 합니다.

내가 선택한 답변을 선택한 이유는 다음과 같습니다. 좋은 답변이 너무 많아요.다들 감사 해요!보시다시피 하나만 선택하는 것은 매우 어렵습니다.내가 선택한 것이 나에게 공감했습니다.나는 그가 설명하는 것과 동일한 경로를 따랐습니다. 동사 + 명사를 사용하려고 시도했지만 고객에게 적용되는 모든 sproc을 찾을 수 없습니다.

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

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

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

도움이 되었습니까?

해결책

마지막 프로젝트의 경우 USP_ [Action] [Object] [Process]를 사용 했으므로 예를 들어 USP_ADDPRODUT 또는 USP_GETPRODUCTLIST, USP_GETPRODUCTDETAIL을 사용했습니다. 그러나 이제 데이터베이스는 700 개의 절차에 이르기 때문에 특정 객체에서 모든 절차를 찾기가 훨씬 어려워집니다. 예를 들어 이제 제품 추가에 대한 50 개의 홀수 추가 절차, Get 등의 경우 50 홀수를 검색해야합니다.

새로운 애플리케이션에서 객체별로 절차 이름을 그룹화 할 계획이므로 USP가 절차를 말하는 것 외에는 USP를 삭제하고 있습니다. 절차 자체.

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

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

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

특히 많은 양의 스프로크가있는 경우 나중에 쉽게 찾을 수 있도록 물건을 그룹화하는 데 도움이됩니다.

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

다른 팁

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

Prefix SP_와 함께 명명 된 저장 절차는 마스터 데이터베이스에 저장된 시스템 스프로크입니다.

SPROC 에이 접두사를 제공하면 SQL Server는 먼저 마스터 데이터베이스에서 컨텍스트 데이터베이스를 찾아서 불필요하게 리소스를 낭비합니다. 또한 사용자가 만든 SPROC가 System Sproc과 동일한 이름을 갖는 경우 사용자 제작 SPROC가 실행되지 않습니다.

SP_ 접두사는 SPROC가 모든 데이터베이스에서 액세스 할 수 있지만 현재 데이터베이스의 맥락에서 실행해야 함을 나타냅니다.

여기에 있습니다 성능 히트의 데모가 포함 된 멋진 설명.

여기에 있습니다 ANT가 의견에 제공 한 또 다른 유용한 소스.

시스템 헝가리어 (위의 "usp" 접두사처럼)은 나를 소름 끼치게 만듭니다.

우리는 유사하게 구조화된 여러 데이터베이스에서 많은 저장 프로시저를 공유하므로 데이터베이스별 데이터베이스의 경우 데이터베이스 이름 자체의 접두사를 사용합니다.공유 프로시저에는 접두사가 없습니다.나는 다른 스키마를 사용하는 것이 다소 추악한 접두사를 완전히 제거하는 대안이 될 수 있다고 생각합니다.

접두사 뒤의 실제 이름은 함수 이름 지정과 거의 다르지 않습니다.일반적으로 "Add", "Set", "Generate", "Calculate", "Delete" 등과 같은 동사 뒤에 "User", "DailyRevenues" 등과 같은 보다 구체적인 명사가 옵니다.

Ant의 의견에 응답:

  1. 테이블과 뷰의 차이점은 데이터베이스 스키마를 설계하는 사람과 관련된 것이지 해당 내용에 액세스하거나 수정하는 사람과 관련이 없습니다.드물지만 구체적인 스키마가 필요한 경우에는 쉽게 찾을 수 있습니다.일반적인 SELECT 쿼리의 경우에는 관련이 없습니다.사실 저는 테이블과 뷰를 동일하게 취급할 수 있다는 점이 큰 장점이라고 생각합니다.
  2. 함수 및 저장 프로시저와 달리 테이블이나 뷰의 이름은 동사로 시작하거나 하나 이상의 명사가 아닐 가능성이 높습니다.
  3. 함수를 호출하려면 스키마 접두사가 필요합니다.실제로 우리가 사용하는 호출 구문은 함수와 저장 프로시저 간에 매우 다릅니다.하지만 그렇지 않더라도 1과 같습니다.적용됩니다:함수와 저장 프로시저를 동일하게 처리할 수 있다면 왜 안 됩니까?

저장된 절차 이름을 시작합니다sp_ 시스템이 모두 SP_로 시작하기 때문에 SQL Server에서는 나쁘다. 일관된 이름 지정 (Hobgoblin-Dom의 정도까지)은 데이터 사전에 따라 자동화 된 작업을 용이하게하기 때문에 유용합니다. 접두사는 SQL Server 2005에서 Schemas를 지원하기 때문에 약간 덜 유용합니다.이 이름은 사용 된 이름의 접두사 방식으로 다양한 유형의 네임 스페이스에 사용할 수 있습니다. 예를 들어, 스타 스키마에서 어둑한 그리고 사실 스키마 및이 컨벤션에서 테이블을 참조하십시오.

저장 프로 시저의 경우, 접두사는 시스템 스프로스에서 응용 프로그램 스프로스를 인출 할 목적으로 유용합니다. up_ vs. sp_ 데이터 사전에서 비 시스템 저장 절차를 식별하기가 비교적 쉽습니다.

tablename_whatitdoes

  • comment_getByid

  • customer_list

  • userpreference_deletebyuserid

접두사 나 어리석은 헝가리어 넌센스가 없습니다. 테이블의 이름은 가장 밀접하게 연관되어 있고 그것이하는 일에 대한 빠른 설명입니다.

위의 한 가지주의 사항 : 나는 개인적으로 항상 zcrud_로 모든자가 생성 된 crud를 접두하여 볼 필요가없는 목록의 끝까지 정렬됩니다.

나는 수년에 걸쳐 거의 모든 다른 시스템을 사용했습니다. 나는 마침내이 것을 개발했는데 오늘 나는 계속 사용하고있다.

접두사 :

  • Gen -General : Crud, 대부분
  • RPT- 보고서 : 자기 설명
  • TSK- 작업 : 일반적으로 절차 논리가있는 무언가, 예정된 작업을 통해 실행됩니다.

액션 지정자 :

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

(절차가 많은 일을하는 경우, 전체 목표는 작업 지정자를 선택하는 데 사용됩니다. 예를 들어, 고객 삽입에는 많은 준비 작업이 필요할 수 있지만 전체 목표는 삽입되므로 "INS"가 선택됩니다.

물체:

Gen (CRUD)의 경우 이것은 영향을받는 테이블 또는보기 이름입니다. RPT (Report)의 경우 보고서에 대한 간단한 설명입니다. TSK (작업)의 경우 이것은 작업에 대한 간단한 설명입니다.

선택적 정화기 :

이들은 절차의 이해를 향상시키는 데 사용되는 선택적 정보입니다. 예는 "by", "for"등을 포함합니다.

체재:

접두사] [액션 지정자] [엔티티] [선택적 명확한 사람

절차 이름의 예 :

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection

나는 항상 저장된 절차를 캡슐화합니다 패키지 (직장에서 Oracle을 사용하고 있습니다). 이는 별도의 객체의 수를 줄이고 코드 재사용에 도움이됩니다.

이름 지정 컨벤션은 취향의 문제이며 프로젝트 시작의 다른 모든 개발자와 동의해야 할 것입니다.

소규모 데이터베이스의 경우 USPTABLENAMEOPERINGNAME (예 : USPCUSTOMERCREATE, USPCUSTOMERDELETE 등)을 사용합니다. 이는 '메인'엔티티 별 그룹화를 용이하게합니다.

더 큰 데이터베이스의 경우 스키마 또는 하위 시스템 이름 (예 : 수신, 구매 등)을 추가하여 그룹화하여 함께 그룹화하기 위해 (SQL Server는 알파벳순으로 표시하는 것을 좋아하기 때문에)

나는 명확성을 위해 이름의 약어를 피하려고 노력합니다 (그리고 프로젝트의 새로운 사람들은 스프로크가 uspusingnoabbreviationsincecreasesceforevereveryone이라는 이름을 지키기 때문에 'Unaicfe'가 무엇을 의미하는지 궁금해 할 필요가 없습니다).

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

표기법:

접두사신청모듈] _ [이름

예시:

P_CMS_USER_USERINFOGET

몇 가지 이유로이 표기법이 마음에 듭니다.

  • 매우 간단한 접두사로 시작하여 코드는 접두사로 구걸하는 객체 만 실행하도록 코드를 작성할 수 있습니다 (예 : SQL 주입을 줄이기 위해)
  • 우리의 더 큰 환경에서, 여러 팀이 동일한 데이터베이스 아키텍처를 실행하는 다른 앱에서 작업하고 있습니다. 응용 프로그램 표기법은 어떤 그룹이 sp를 소유하고 있는지 지정합니다.
  • 모듈 및 이름 섹션은 단순히 상속인을 완성합니다. 모든 이름은 그룹/앱, 모듈, 상속인의 기능과 일치 할 수 있어야합니다.

나는 항상 사용합니다 :

USP [테이블 이름] [액션] [추가 세부 사항

"TBLUSER"라는 테이블이 주어지면 다음과 같습니다.

  • USPUSERCREATE
  • USPUSERSELECT
  • uspuserselectbynetworkid

절차는 알파벳순으로 테이블 이름과 기능별로 정렬되므로 주어진 테이블에 무엇을 할 수 있는지 쉽게 알 수 있습니다. Prefix "USP"를 사용하면 다른 절차, 여러 테이블, 기능, 뷰 및 서버와 상호 작용하는 1000 줄 절차를 작성하는 경우 (예를 들어) 전화하는 경우 알려줍니다.

SQL Server IDE의 편집기가 비주얼 스튜디오만큼 좋을 때까지 접두사를 보관하고 있습니다.

응용 프로그램 prefix_ 작동 prefix_ 관련 데이터베이스 개체의 설명 (밑줄 사이의 공간을 빼고 - 나타나기 위해 공백을 넣어야했습니다).

우리가 사용하는 작동 접두사 -

  • 가져 오기” - 레코드 세트를 반환합니다
  • ins” - 데이터를 삽입합니다
  • upd” - 데이터를 업데이트합니다
  • ” - 데이터를 삭제합니다

예를 들어

wmt_ ins _ customer _details

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

장점

동일한 응용 프로그램과 관련된 모든 저장된 절차는 이름별로 그룹화됩니다. 그룹 내에서 동일한 종류의 작업 (예 : 인서트, 업데이트 등)을 수행하는 저장된 절차가 함께 그룹화됩니다.

이 시스템은 우리에게 잘 작동하며 약. 내 머리 꼭대기에서 하나의 데이터베이스에 1000 개의 저장된 절차.

지금 까지이 접근법에 대한 단점을 발견하지 못했습니다.

getxxx- @id를 기반으로 xxx를 가져옵니다

getAllXXX- 모든 XXX를 가져옵니다

PUTXXX -PASSED @ID IS -1이면 XXX를 삽입합니다. 다른 업데이트

delxxx- @id를 기반으로 xxx를 삭제합니다

USP_ 명명 컨벤션은 아무도 좋은 사람이 없다고 생각합니다.

과거에는 CRUD 작업을 위해 Get/Update/Insert/Delete Prefixes를 사용했지만 이제는 LINQ에서 SQL 또는 EF를 사용하여 대부분의 CRUD 작업을 수행하기 때문에 전적으로 사라졌습니다. 새로운 응용 프로그램에 저장된 Procs가 거의 없기 때문에 명명 규칙은 더 이상 예전처럼 중요하지 않습니다. ;-)

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

만약 우리가 유산 제약 조건이 없다면, 우리는 접두사를 사용하지 않을 것이라고 확신합니다.

접두사 후에 우리는 보통 절차의 수행을 설명하는 동사와 우리가 작동하는 엔티티의 이름을 설명하는 동사로 SP 이름을 시작합니다. 엔티티 이름의 복수화가 허용됩니다 - 우리는 가독성을 강조하려고 노력하므로 절차가 이름만으로 수행하는 작업이 분명합니다.

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

shopGetCategories
shopUpdateItem

나는 당신이 논리적이고 일관성이있는만큼 당신의 접두사가 길고 정확히 중요하다고 생각하지 않습니다. 개인적으로 나는 사용합니다

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

Action Description은 Get, Set, Archive, Insert, Delete 등과 같은 작은 범위의 일반적인 작업 중 하나입니다. 예를 들어 프로세스 설명은 짧지 만 설명 적입니다.

spu_archiveCollectionData 

또는

spu_setAwardStatus

내 기능을 비슷하게 지정하지만 UDF_로 접두사

나는 사람들이 절차 명명을 위해 의사-헝가리 표기법을 사용하려고 시도하는 것을 보았습니다. 제 생각에는 내 의견으로는 그것이 드러나는 것보다 더 많이 숨 깁니다. 내 절차를 알파벳순으로 나열하는 한, 기능으로 그룹화 된 것을 볼 수 있습니다.

SQL Server의 SP_*를 피하십시오. 모든 시스템 저장된 사후 저장된 사후는 SP_로 시작하므로 시스템이 이름에 해당하는 객체를 찾는 것이 더 어려워집니다.

따라서 SP_ 이외의 다른 것으로 시작하면 상황이 쉬워집니다.

그래서 우리는 Proc_의 일반적인 이름 지정을 사용하여 처음부터 시작합니다. 따라서 하나의 큰 스키마 파일이 표시되면 절차를 쉽게 식별 할 수 있습니다.

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

Proc_Poll_Interface, Proc_Inv_Interface 등.

이를 통해 우리는 인벤토리 등을 수행하는 여론 조사 대 여론 조사의 작업을 수행하는 모든 저장된 Procs를 찾을 수 있습니다.

어쨌든 접두사 시스템은 문제 영역에 따라 다릅니다. 그러나 Al은 사람들이 편집을 위해 Explorere 드롭 다운에서 저장된 절차를 quicly로 찾을 수있게하더라도 비슷한 일을해야한다고 말했습니다.

다른 예를 들어 기능.

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

우리는 기능 기반 명명 COZ Procs가 테이블과 같은 정적 객체보다는 코드 / 기능과 유사합니다. Procs가 하나 이상의 테이블과 함께 작동하는 것은 도움이되지 않습니다.

Proc이 단일 이름으로 처리 할 수있는 것보다 더 많은 기능을 수행 한 경우, Proc가 필요한 것보다 훨씬 더 많은 일을하고 다시 분할 할 시간을 의미합니다.

도움이되기를 바랍니다.

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

마지막 두 프로젝트에는 우리가 사용한 것과 같은 다른 트렌드가 있습니다.

데이터를 얻으려면 : su003Ctablename> _G
데이터를 삭제하려면 : su003Ctablename> _디
데이터 삽입 : su003Ctablename> _나
데이터 업데이트 : su003Ctablename> _유

이 이름 지정 규칙은 또한 단어를 접두사하여 프론트 엔드에서 따릅니다. DT.

예시:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

우리의 응용 프로그램에서 위 이름 지정 규칙의 도움으로 우리는 좋은 이름을 가지고 있습니다.

두 번째 프로젝트에서는 Lill 차이와 동일한 명명 규칙을 사용했습니다.

데이터를 얻으려면 : SP_u003Ctablename> G
데이터 삭제 : SP_u003Ctablename> 디
데이터 삽입 : SP_u003Ctablename> 나
데이터 업데이트 : SP_u003Ctablename> 유

예시:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top