누구나 TSQL에 대한 코딩 표준을 추천 할 수 있습니까?

우리는 오랫동안 .Net 코드에 대한 코딩 표준을 가지고 있었으며 시간이 지남에 따라 진화하는 코드를 적용하는 방법에 대한 아이디어를 얻을 수있는 평판 좋은 출처가 여러 개있는 것 같습니다.

우리 제품에서 사용하도록 작성된 SQL에 대한 표준을 만들 수 있기를 원하지만 잘 작성된 SQL을 결정하는 것에 대한 합의에 대한 자료가없는 것 같습니다.

coding-standards sql-server

— 롤랜드 쇼
소스

Pinal Dave는 자신의 사이트 에 코딩 표준 목록을 가지고 있습니다 . 그것들은 일련의 표준에 대한 공정한 기초처럼 보입니다.

— 윌 A

SO에 대한 관련 질문 이 있습니다 .

— Scott Whitlock

식별 만 다루는 @Scott; 이름 지정, 커서 사용 / 저장 프로 시저 / 데이터 유형 선택 또는 실제로 코드 품질에 영향을 미치는 모든 것

— Rowland Shaw

정확히 내가 왜 "중복"이 아니라 "관련"이라고 말했는지.

— Scott Whitlock

답변:

내 경험상 내가 찾은 주요 사항은 다음과 같습니다.

테이블 및 열 이름 지정-ID 유형 열에 ID, 참조 또는 번호를 사용하는지, 이름에 단수 또는 복수를 사용하는지 확인하십시오 (표 이름에 공통적 인 복수 (예 : THINGS, 열 이름에 단일-예) THING_ID). 나에게 가장 중요한 것은 사람들이 시간을 낭비하지 않는 일관성입니다 (예를 들어 테이블 이름이 결코 단수라는 것을 직관적으로 알고 있기 때문에 누군가 THING을 테이블 이름으로 넣은 오타가 발생하지 않습니다).
모든 생성은 파일의 일부로 드롭 (기존 객체에 조건부)을 포함해야합니다. 권한 부여를 자신에게 포함시킬 수도 있습니다.
선택, 업데이트, 삽입 및 삭제는 한 줄에 하나의 열 이름, 하나의 테이블 이름 및 하나의 where 절 / 순서를 절별로 배치해야 디버깅 중에 한 번에 하나씩 쉽게 주석을 달 수 있습니다.
특히 혼동 될 수있는 오브젝트 유형의 접 두부 (보기에서 v가 가장 중요 함). 여전히 적용되는지 확실하지 않지만 시스템 프로 시저 이외의 저장 프로 시저가 sp_를 시작하는 데 비효율적이었습니다. 어쨌든 usp_를 구별하는 가장 좋은 방법은 내가 가장 최근에 사용한 것입니다.
트리거 이름에 업데이트 / 삽입 / 삭제 여부와 적용되는 테이블이 포함되어야하는 방법을 나타내는 표준입니다. 선호하는 표준은 없지만 중요한 정보이므로 쉽게 찾을 수 있어야합니다.
이전 버전의 SQL Server 또는 2005 년 이후에 존재해야하는 스키마의 개체 소유권 표준. 그것이 무엇인지 당신의 요구이지만 당신은 누군가가 무엇을 소유하고 있는지 / 어디에 살고 있는지 추측해서는 안됩니다.) 스키마 / 소유자가 CREATE 스크립트에 포함되어 잘못 생성 될 가능성을 최소화해야합니다.
SELECT *를 사용하는 사람은 누구나 자신의 소변 잔을 마신다는 표시입니다.
게으름을 포함하지 않는 정말 좋은 이유가 없다면 처음부터 기본 키 / 외부 키 관계를 유지, 유지 및 유지해야합니다. 이것은 결국 플랫 파일이 아닌 관계형 데이터베이스이며 고아 레코드는 어느 시점에서 지원 수명을 단축시킬 것입니다. 또한 지금하지 않으면 데이터를 얻은 후 작업의 10 배이기 때문에 이벤트 후에 구현하지 않을 것이라고 약속 할 수 있습니다. 관계)).

나는 무언가를 놓쳤다 고 확신하지만, 나에게는 그것들이 적절한 수의 상황에서 실제로 혜택을 제공하는 사람들입니다.

그러나 모든 표준과 마찬가지로 더 적습니다. 코딩 표준이 길수록 사람들이 표준을 읽고 사용할 가능성이 줄어 듭니다. 일단 간격이 잘 잡힌 두 페이지를 지나면 사람들이 실제로 그 일을 할 가능성이 줄어들 기 때문에 실제 세계에서 실제로 큰 차이를 일으키지 않는 내용을 삭제하려고합니다.

편집 : 소유권 섹션의 스키마를 포함하여 count (*)에 대한 잘못된 팁을 제거하는 두 가지 수정-아래 주석을 참조하십시오.

— 존 홉킨스
소스

이상한 선택이 있습니다 ... "SELECT COUNT (*)"가 나쁩니 까? 스키마에 대해 들어 본 적이 있습니까 (소유자와 동일하지 않음)? 그래도 다른 사람들은 훌륭합니다

— gbn

@ Jon Hopkins-왜 SELECT *를 사용하는 것이 나쁜지 알고 있습니다. 왜 SELECT COUNT (*)를 사용하는 것이 좋지 않은지 말할 수 있다면 좋을 것입니다.

— k25

@gbn @ k25-몇 년 전 (2002?) 나는 DBA가 카운트 (*)에 매우 뜨거웠지만 귀하의 질문에 대한 응답으로 인터넷 검색은 이것이 구식 인 것 같습니다 (사실이라면). sqlservercentral.com/articles/Performance+Tuning/adviceoncount/… (등록 필요). 그녀는 주로 Oracle DBA 였으므로 SQL 옵티마이 저의 문제라고 가정 한 진정한 문제 일 수 있습니다.

— Jon Hopkins

@gbn-예, 소개되었으므로 상대적으로 손을 though지만 자동 반응은 사용자였습니다. 스키마를 다루기 위해 답변을 업데이트하겠습니다.

— Jon Hopkins

@gbn, @ k25-카운트 (*)에서 더 많은 파기. 분명히 이것은 Oracle 7 및 이전 버전의 문제였으며 8i 이상에서 수정되었습니다. SQL Server에서 문제가되었는지는 확실하지 않지만 더 이상은 아닙니다. 내 DBA가 오래된 것 같습니다.

— Jon Hopkins

잘 작성된 SQL을 결정하는 것에 대한 합의에 대한 자료가 없습니다.

합의가 없기 때문입니다. 예를 들어, Jon Hopkins의 목록에있는 항목의 최소 절반에 대해 다른 답변을 얻을 수 있으며 그의 목록에있는 세부 정보의 양을 기준으로 우리는 생계를 위해 데이터베이스를 사용하는 것이 안전한 추측입니다.

즉, 코딩 표준은 여전히 좋은 것입니다. 팀의 모든 사람들이 이해하고 동의하는 표준이 더 좋습니다. 그 표준은 더 잘 따르기 때문입니다.

— 래리 콜먼
소스

+1. 가장 중요한 것은 팀 간의 일관성을 유지하는 것입니다.

— Dean Harding

관심이 없다면 어떻게 다르게 하시겠습니까? 그것들은 주로 맛의 문제입니까 (레이아웃 등) 또는 "하드"오류가 있습니까?

— Jon Hopkins

@Jon : 딱딱한 오류가없고, 단수의 테이블 이름, 트리거의 증오 등과 같은 주관적인 것들이 있습니다. BTW, "SELECT *"는 "EXISTS ()"안에 있습니다.

— Larry Coleman

공정한 예 (그리고 나는 그것을 EXISTS와 함께 사용하고 소변을 마시도록 강요하지 않습니다).

— Jon Hopkins

Jon Hopkins의 답변 외에도 ...

별도의 내부 객체와 외부 객체
- 제약 조건 및 인덱스 등의 IX, UQ, TRG, CK 등
- 클라이언트 용 소문자 또는 CapsCase (예 : uspThing_Add)
내부 객체의 경우 "기본이 아닌"경우 명시 적
- UQ = 고유 제한
- UQC = 고유 클러스터 제약
- PK = 기본 키
- PKN = 비 클러스터 기본 키
- IX = 색인
- IXU = 고유 색인
- IXC = 클러스터형 인덱스
- IXCU 또는 IXUC = 고유 클러스터 색인
스키마를 사용하여 이름 지정 + 권한을 단순화하십시오. 예 :
- 내부 프로세스를위한 Helper.xxx
- udfs 용 HelperFn.xxx
- 일부 직면 코드에 대한 WebGUI.xxx
- 테이블의 데이터 및 / 또는 히스토리 및 / 또는 스테이징

— gbn
소스