접두사 열 이름이 나쁜 습관으로 간주되는 이유는 무엇입니까?

인기있는 SO 게시물 에 따르면 테이블 이름을 접두사로 쓰는 것은 나쁜 습관으로 간주됩니다. 우리 회사에서는 모든 열 앞에 테이블 이름이 붙어 있습니다. 읽기가 어렵습니다. 이유를 잘 모르겠지만이 이름은 실제로 회사 표준입니다. 명명 규칙을 참을 수는 없지만 추론을 뒷받침 할 문서는 없습니다.

내가 아는 것은 AdventureWorks를 읽는 것이 훨씬 간단하다는 것입니다. 년 이 우리 회사의 DB 테이블을 볼 수, 사람과 열 이름이있을 수 있습니다 :

Person_First_Name
또는 아마도
Person_Person_First_Name (사람이 2x 인 이유를 묻지 마십시오)

열 이름을 미리 수정하는 것이 좋지 않은 이유는 무엇입니까? 밑줄도 SQL에서 악으로 간주됩니까?

밑줄은 타이핑하기가 어렵지 않습니다. 나쁜 점은 기존의 모든 개체를 수정하지 않고 표준 중류를 변경하는 것입니다. 이제 personId, Person_id 등이 있으며 밑줄을 사용하는 테이블을 기억할 수 없습니다. 이름이 일관성이 없으면 (개인적으로 이름이 마음에 들지 않더라도) 쉽게 코딩 할 수 있습니다.

개인적으로 열에서 테이블 이름을 사용해야하는 유일한 위치는 ID 열에 있습니다. 방대한보고 쿼리를 수행 한 사람이라면 누구나 알 수 있듯이 ID 만 사용하면 데이터베이스 디자인에서 반 패턴이됩니다. 보고서를 작성할 때마다 쿼리에 12 개의 열이 있습니다.) 또한 같은 이름을 가진 다른 테이블의 FK를 쉽게 알 수 있습니다.

그러나 성숙한 데이터베이스에서는 기존 표준을 변경하는 것보다 더 많은 작업이 필요합니다. 그것이 표준임을 인정하고 계속 진행하십시오. 먼저 수정해야 할 더 중요한 것들이 있습니다.

열 이름 접두사에 대한 인수는 여러 테이블을 조인 할 때와 쿼리 작성자가 별칭을 사용하지 않을 때 이름 "충돌"을 방지합니다.

SELECT person.name, company.name FROM person JOIN company ON ...

SELECT * FROM person JOIN company ON ...

두 쿼리 모두 자신이 속한 엔티티를 "통신"하지 않고 두 개의 "name"열 ( name_1, name_2 )을 갖 습니다. 그리고 생성 된 열 이름을 확신 할 수 없습니다 (name_2 또는 name_3 또는 ...). 테이블 이름 접두사를 사용하는 경우 열 이름은 person_name , company_name 이므로 해당 엔티티가 속한 각 이름을 알 수 있으며 열 이름이 일정하게 유지됩니다 (예를 들어 JDBC를 사용하여 Java로 가져 오는 경우) ).

앨리어싱을 사용하는 경우 두 가지 인수를 모두 무시할 수 있지만 회사에서 시행하는 대부분의 코딩 규칙은 많은 (주니어) 프로그래머가 모범 사례를 따르지 않은 결과라고 생각합니다. 예를 들어, SELECT 문에서 와일드 카드를 사용하면 이름 접 두부없이 문제점이 발생할 수 있습니다.

테이블 및 열 이름의 밑줄은 소문자와 밑줄을 구분 기호로 사용하기 때문에 광범위하게 사용합니다. 소문자 만 사용하면 식별자를 SQL 키워드 (모든 대문자로 입력)와 구별 할 수 있습니다.

SELECT person_name, COUNT(bought_product) FROM bought_products WHERE person_name LIKE 'A%'

이러한 종류의 접두사를 열 이름에 추가하면 테이블을 더 어렵게 만들 수 있습니다. 예를 들어, 결국 테이블 이름을 변경하고 싶다는 것을 알고 있다면 전체 테이블 구조를 수정해야합니다 (예 : 테이블 이름뿐만 아니라 모든 열 이름). 또한 테이블의 인덱스와 쿼리하는 클라이언트의 코드를 업데이트하기가 더 어려워집니다.

공통된 열 이름 (일반적으로 ID 만, 때로는 이름 만)에 대해 너무 모호한 경우 (링크에서 Patrick Karcher의 답변에 따라) 예외적으로 사용되는 경우 예외가 있습니다 .

또 다른 모범 사례는 항상 쿼리에서 열과 개체를 한정하는 것입니다. 따라서 열 접두사가 불분명 해지고 코드가 복잡해집니다.

이것들을 비교하십시오 : 눈에서 가장 쉬운 것은 무엇입니까?

SELECT P.name, P.Salary FROM dbo.Person P

SELECT Person.Name, Person.Salary FROM dbo.Person Person

SELECT dbo.Person.name, dbo.Person.Salary FROM dbo.Person

SELECT Person.Person_name, Person.Person_Salary FROM dbo.Person Person

일반적으로 유비쿼터스 표준은없는 것 같습니다. 귀하가 연결 한 질문에는 완전히 다른 규칙을 사용하여 투표가 많은 답변이 여러 개 있습니다. 물론 모든 사람들은 자신의 표준을 지키려고하며, 프로젝트에서 일관된 규칙을 유지하는 것이 훨씬 더 중요합니다.

즉, 접두사 열 이름은 과도하게 보입니다. 작업중인 테이블을 이미 알고 있으며 동일한 이름을 가진 다른 테이블의 두 열이있는 상황은 테이블 또는 열 별칭을 사용하여 쉽게 해결할 수 있습니다.

TSQL에서는 모호성을 피하기 위해 TableName.FieldName 형식의 필드를 참조 할 수 있으므로 필드 이름에 테이블 이름을 추가하면 실제로 가독성이 없어져 TableName.TableName_FieldName 또는 이와 유사합니다. 밑줄을 사용하거나 사용하지 않는 것이 더 개인적인 선택이라고 생각합니다. 나는 CamelCase를 선호하고 TableName_Temp와 같은 접미사 또는 유사한 것을 추가하려고 할 때 _를 사용하지만 그저 나뿐입니다.

한 번은 짧은 코드를 사용하여 열 접두사를 사용하기로 결정한 시스템에서 작업했습니다. PK 필드는 "전체 테이블 이름"을 접두어로 사용했으며 다른 모든 열은 접두사로 2-4자를 일관되게 사용했습니다. 각 열은 데이터 도메인을 접미사로 사용했습니다. 일관되게 수행하면 매우 좋고 깨끗할 수 있습니다. 하나의 유형 또는 다른 유형의 명명 표준이 거친 코딩을 의미한다는 것은 말이되지 않습니다. 일관된 표준이 존재하는 것이 중요합니다. 명확한 표준이 없기 때문에 불일치하는 많은 데이터베이스를 보았으며 다른 것보다 많은 것이 데이터 구조에 문제가있을 수 있음을 나타냅니다. 데이터베이스 디자이너가 개체와 자식의 이름을 일관되게 지정할 수 없다면

접두사는 예방을 위해 설계된 문제를 야기하기 때문에 나쁜 습관입니다. 언급했듯이 접두사 열을 읽기가 매우 어렵습니다. 두 테이블을 조인하는 쿼리에서 중복 된 열 이름으로 끝나는 경우이를 해결하거나 특정 테이블을 지속적으로 조인하는 경우이를 수행하는 뷰, 저장 프로 시저 또는 테이블 사용자 정의 함수입니다.

테이블 이름에 밑줄을 사용하는 한 종교적인 주장입니다. 결국 가시성을 높이면 더 쉽게 갈 수 있습니다. 나는 일반적으로 열이나 테이블 이름에 공백이나 테이블이 없습니다. 그러나보고 패키지에서만 사용되었거나 CSV 파일로 내 보낸 테이블이나 뷰에는 예외가있을 수 있습니다.

많은 데이터베이스에는 열 이름 (예 : Oracle)의 문자 수에 대한 제한이 있습니다.

긴 열 이름을 허용하는 데이터베이스로 작업하고 있지만 나중에 해당 구조를 다른 데이터베이스 시스템으로 마이그레이션하기로 결정하면 접두사가 열 이름이 유효하지 않을 가능성을 높입니다.

지금은 SQL Server를 사용하고 있지만 미래를 예측할 수있는 사람은 없으며 나중에 소프트웨어가 여러 데이터베이스에서 작동해야 할 수도 있습니다.

데이터 사전 (또는 "레지스트리")을 작성하십시오. 즉, 모델에 이름, 설명 등 모든 데이터 요소가 포함 된 문서를 의미합니다. 예를 들어 테이블 이름은 언급하지 않아야합니다. 'ID', 'Type'및 'Code'와 같은 이름을 어떻게 명확하게 하시겠습니까?

한 가지 방법은 국제 표준 ISO / IEC 11179 의 지침을 따르는 것입니다. 결국 바퀴를 재발 명하는 이유는 무엇입니까? 기본 구조는 다음과 같습니다.

[Object] [Qualifier] Property RepresentationTerm

요소 사이에 구분 기호가 있습니다. SQL은 열 이름에 공백이 있으면 좋지 않으며 밑줄은 시각적으로 잘 작동합니다.

조직의 누군가가와 같은 요소 이름을 제안 할 때이 가이드 라인을 따르려고한다고 생각 Person_Person_First_Name합니다.

내가 보여주는 예는 영국 국가 보건 서비스 (NHS) 데이터 사전 입니다.

그래서 나는 당신이 소리로 작업 해야하는 명명 규칙이 너무 나쁘지 않다고 생각합니다.

SQL에서 구현 예에서, 같은 일부 사람들은 개체를 생략 할 테이블 이름은 상황에 맞는 예를 제공 예선 및 속성 하위 요소가 person_first_name된다 first_name에 Person그러나, 데이터 요소는 단순히 그 이름을 엄지 손가락의 규칙을 변경하지 않도록 테이블 등 물리적 모델의 위치로 인해 좋은 것으로 보입니다. 이 규칙을 따르는 것이 좋지 않다고 생각하는 사람은 사용한 모든 이름 변형을 문서화해야합니다. :)

Joe Celko 's Programming Style 책 에서 열 이름의 구분 기호로 밑줄을 선호하는 증거를 포함하여 ISO 11179에 대한 요약이 제공 됩니다.

어떤 사람들은 코드에서 데이터가 어떤 테이블에서 왔는지 쉽게 알 수 있지만 객체 지향 시스템에 대해 이야기하는 경우 이름의 컨텍스트를 사용하여 데이터의 출처,이 경우 테이블 이름을 알아야합니다.

개인적으로 테이블 이름 접두사는 개발자가 매우 숙련되지 않았 음을 나타내며 더 깊이 파고 들수록 다른 많은 나쁜 코딩 규칙을 찾을 수 있으며 앱에 테이블이 너무 많거나 버그가 있다고 추측 해야하는 경우가 있습니다.