저장 프로 시저 이름 지정에 대한 다양한 규칙을 보았습니다.
어떤 사람들은 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의 의견에 대한 답변 :
- 테이블과 뷰의 차이는 데이터베이스 스키마를 설계하는 사람과 관련이 있으며, 그 내용에 액세스하거나 수정하는 사람이 아닙니다. 드물지만 스키마 세부 사항이 필요한 경우 쉽게 찾을 수 있습니다. 캐주얼 SELECT 쿼리의 경우 관련이 없습니다. 사실 저는 테이블과 뷰를 똑같이 취급 할 수 있다는 것이 큰 장점이라고 생각합니다.
- 함수 및 저장 프로 시저와 달리 테이블 또는 뷰의 이름은 동사로 시작하거나 하나 이상의 명사가 아닌 다른 이름 일 가능성이 없습니다.
- 함수를 호출하려면 스키마 접두사가 필요합니다. 사실, 호출 구문 (어쨌든 우리가 사용하는)은 함수와 저장 프로 시저간에 매우 다릅니다. 그러나 그렇지 않은 경우에도 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을 사용하고 있습니다). 이렇게하면 개별 개체의 수가 줄어들고 코드 재사용에 도움이됩니다.
명명 규칙은 취향의 문제이며 프로젝트 시작시 다른 모든 개발자와 동의해야합니다.
