MSDN 에서 명명 지침 을 찾았 지만 Microsoft의 MSSQL 데이터베이스에 대한 지침입니까?
답변
SQL Server의 AdventureWorks 데이터베이스 에서 사용되는 명명 규칙 은 스타일 측면에서 많은 모범 사례를 보여줍니다.
요약:
- 개체 이름을 쉽게 이해할 수 있습니다.
- 테이블 이름이 복수화되지 않음 ( “Users”가 아닌 “User”테이블)
- 약어는 적지 만 허용됨 (예 : Qty, Amt 등)
- 특정 열 이름 (예 : rowguid)을 제외하고 독점적으로 사용되는 PascalCase
- 밑줄 없음
- 특정 키워드가 허용됩니다 (예 : 이름)
- 저장 프로시 저는 “usp”로 시작됩니다.
- 함수 앞에는 “ufn”이 붙습니다.
여기에서 자세한 내용을 확인할 수 있습니다.
한 가지주의 사항 : 데이터베이스 명명 규칙은 매우 논란이 될 수 있으며 제가 만난 대부분의 데이터베이스 개발자는 자신의 스타일에 개인적인 이해 관계를 가지고 있습니다. 테이블 이름을 “OrderHeader”또는 “OrderHeaders”로 지정해야하는지에 대한 열띤 논쟁을 들었습니다.
답변
아니요, 제공 한 링크의 관행을 염두에 두는 것이 좋습니다.
저장 프로 시저 이름 지정과 관련하여 “sp_”접두사를 붙이지 마십시오 .이 링크에서 이유에 대해 자세히 알아볼 수 있습니다 .
“이 접두사는 시스템 저장 프로 시저 식별 용으로 예약되어 있으므로 저장 프로 시저 앞에 sp_를 붙이지 마십시오.”
답변
@ 8kb (작성 당시)의 답변에서 “스타일 측면에서 모범 사례”가 무엇을 의미하는지 모르겠습니다. 분명히 나열된 항목 중 일부 ( “테이블 이름은 복수형이 아닙니다”, “밑줄 없음”등)은 명백하게 주관적인 스타일 선택 일뿐입니다. 문서화 팀 리더의 개인적 선호도가 여기서 가장 큰 요인이라고 생각했을 것입니다.
일반적으로 SQL의 휴리스틱과 관련하여 (T-SQL과 같은 독점 SQL과는 대조적으로) 주제에 대한 책은 한 권 밖에 없습니다 : Joe Celko의 SQL 프로그래밍 스타일. SQL Server의 AdventureWorks 데이터베이스에 대한 많은 선택 사항이 Celko의 지침과 충돌합니다.
Celko의 명명 규칙은 국제 표준 ISO 11179를 기반으로합니다. 예를 들어 구분 문자 (예 : 밑줄)를 사용하여 이름의 요소를 구분해야합니다. 다른 스타일 선택도 마찬가지로 연구를 통해 백업됩니다. 예를 들어 열 이름에 소문자 만 사용하므로 육안으로 스캔하는 데 도움이됩니다. 의심 할 여지없이 주관적인 개인적 선호도는 현장에서 수년간의 경험을 바탕으로합니다.
장점은 최근 몇 년 동안 SQL Server 문서에서 개선 된 점입니다. 예를 들어 SQL 키워드를 대문자로, 세미콜론을 문으로 구분하는 등의 작업이 있습니다. Adventure works는 Northwind와 pub에서 크게 향상되었습니다. 이제 Management Studio의 스크립팅 기능이 눈에 좀 더 쉬운 코드를 뱉어 낼 수없는 이유는 무엇입니까?!
