데이터베이스 테이블 및 뷰 이름 지정

Question

최근 동료에게 왜 모든 데이터베이스 테이블 이름 끝에 _TABLE을 포함 시켰는지 물었습니다. 그들은 그들이 일했던 다른 조직에서 표준이라고 말했습니다. 다른 동료들은보기 시작시 V_를 사용합니다.
좋은 방법입니까?

Answer 1

일관성이 가장 좋은 방법입니다. 개체 이름 끝에 _TABLE 또는 _VIEW를 추가하는 것은 책에서 과도하게 이루어 지지만 데이터베이스가 그런 식으로 설계된 경우 관례에서 벗어나지 않습니다.

동료가 'local'표준을 확인하지 않고 이전 조직의 이름 지정 규칙을 새 조직으로 가져 오는 것이 나쁜 습관입니다. http://vyaskn.tripod.com/object_naming.htm에서

Answer 2

:

데이터베이스 개체에 대한 많은 다른 명명 규칙이 존재, 그들 중 누구도 잘못하지 않습니다. 명명 규칙을 고안 한 사람이 개인적으로 더 선호합니다. 그러나 조직에서는 한 사람 (또는 그룹)이 데이터베이스 명명 규칙을 정의하고 표준화하며 다른 사람들은 자신이 좋아하는지 여부에 관계없이이를 따릅니다.

조직에서 구현/생성하는 방법에 대한 자세한 내용은 full article을 참조하십시오.

Answer 3

v_ 또는 vw_ 접두어를 사용하면 SELECT 쿼리를 자주 읽는 경우 유용 할 수 있습니다. 보기 또는 표에서 선택 중인지 빠르게 확인할 수 있습니다. 접두사보기 또는 접미사 표는 충분해야하며 둘 다 필요하지 않습니다. 우리는 뷰 접두사를 사용합니다.

또한 "모듈"접두사를 사용하여 기능 그룹 주변의 표 및 클러스터를 클러스터링합니다. 예를 들어, 청구 관련 테이블을 BIL_ * 및 청구 관련 뷰 VW_BIL_ *라고합니다. 모듈 명명은 SSMS에서 서로 가까이에있는 관련 테이블과 뷰를 유지합니다.

Answer 4

뷰를 표준으로 사용하는 것이 특히 눈에 안좋은 이유는 테이블 이름을 바꾸고 이전 이름을 모방 한 오래된 이름으로보기를 만드는 데이터베이스를 리팩터링하는 가장 좋은 방법 중 하나를 사용하지 못하게하기 때문입니다 구조를 변경하는 동안 아무것도 변경되지 않지만 변경 사항을 적용하기 전에 모든 기존 참조를 찾고 수정할 수 있습니다.

나는 또한 실제 문제는 다른 조직의 명명 규칙을 사용하고 현재 조직의 명명 규칙을 무시한다는 아이디어에 akf입니다. 이걸 빨리 밟았을 것이고 당신의 표준이 무엇이든지간에 모든 사물과 관련 코드를 바꾸거나 이것이 계속 문제가 될 것이라고 주장합니다.

Answer 5

akf가 질문에 잘 대답했다고 생각합니다. 그리고 HLGEM은 리펙토링에 대한 좋은 지적입니다.

그러나이 접두사를 접두어/접미사 규칙이없는 것에 추가 할 것입니다. SQL Server (및 다른 데이터베이스)에서는 동일한 소유자와 동일한 스키마에 같은 이름의 테이블과 뷰를 가질 수 없습니다. 테이블에 대해 비정규 화 된 뷰를 만드는 것이 일반적인 패턴입니다. 테이블과 뷰를 구별하는 명명 규칙을 채택하지 않은 경우 EMPLOYEE_V 대신 EMPLOYEE_DENORM과 같은 뷰에 대한 재미있는 이름이 생길 수 있습니다.

HLGEM과 같은 리팩터링이 필요하다면 명명 규칙에 따라 허용 될 수 있습니다. 그렇게하면 접두어 나 접미어가없는 뷰를 "리팩토링"뷰로 쉽게 식별 할 수 있습니다.

Answer 6

모든 camelCase에서 내 테이블의 이름과 필드 이름을 선호합니다. 예를 들면 ...

CREATE TABLE [crm].[company] 
(
    [id] INT NOT NULL PRIMARY KEY, 
    [companyName] NVARCHAR(255) NOT NULL 
) 

보기에는 단어 "보기"가 붙습니다. 예를 들어 ...

CREATE VIEW [crm].[viewFullEmployee] 
    AS SELECT e.id, e.companyId, e.niceId, e.startDate, e.fullPart, p.firstName, p.middleName, p.lastName, p.active, p.birthDate, p.email, p.alternateEmail, p.phone, p.phoneExt, p.homePhone, p.mobilePhone, p.jobTitle, p.suffix, p.prefix FROM [crm].[Employee] as e FULL JOIN [crm].[person] as p on e.id = p.id 

는 또한 스키마 속으로 모든 것을 분할 나는 아무것도 DBO에 없기 때문에 항상 내 쿼리 것들에 대한 스키마를 지정하는 저를 강제로 기본 스키마를 사용하지 마십시오.

나는 그것 앞에 단어보기가 부족하여 무언가가 탁상이라고 알고 있습니다. 또한 같은 이름의 테이블과 뷰를 갖는 것을 방지합니다.

"employee_v"와 같은 밑줄 이름을 사용하는 것을 좋아하지 않습니다. T4 템플릿 인 "PetaPoco"로 모든 데이터 레이어 코드를 생성하고 유형을 참조 할 때 코드에 _을 입력하지 않아도되기 때문입니다.

나는 단지 등이 더 나은

var person = uow.Db.Fetch<Models.viewFullEmployee>("SELECT * FROM [crm].[viewFullEmployee]"); 

나는 그들이 내가 너무 많은 사람들이 할 내용은 "SP_"와 같은 접두사를 필요로하지 않는 느낌이 저장 프로 시저에 관해서는

var person = uow.Db.Fetch<Models.fullEmployee_V>("SELECT * FROM [crm].[fullEmployee_V]"); 

대. EXEC 또는 Create Procedure 또는 Alter Procedure의 접미사로 인해 사용중인 저장 프로 시저라는 것을 알고 있습니다. "addUpdatePerson", "getUserPermissions"등과 같은 저장 프로 시저의 이름을 지정합니다.

접두어는 "fnValidateEmail"과 같은 함수에 저장 프로 시저 이름과 충돌 할 수 있으므로 사용합니다.