데이터베이스, 테이블 및 열 명명 규칙? [닫은]

데이터베이스를 디자인 할 때마다 항상 데이터베이스에 항목의 이름을 지정하는 가장 좋은 방법이 있는지 궁금합니다. 나는 종종 나 자신에게 다음과 같은 질문을한다.

1. 테이블 이름이 복수 여야합니까?
2. 열 이름이 단수 여야합니까?
3. 테이블이나 열을 접두사로 사용해야합니까?
4. 항목 이름을 지정할 때 대소 문자를 사용해야합니까?

데이터베이스에서 항목 이름을 지정하기위한 권장 지침이 있습니까?

Microsoft의 SQL Server 샘플 데이터베이스를 확인하는 것이 좋습니다. https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks 샘플은 데이터베이스 개체 구성에 스키마 이름을 사용하는 매우 명확하고 일관된 명명 규칙을 사용합니다.

1. 테이블의 단수 이름
2. 단수의 단수 이름
3. 테이블 접두사에 대한 스키마 이름 (예 : SchemeName.TableName)
4. 파스칼 케이싱 (일명 어퍼 카멜 케이스)

여기에 늦게 대답했지만 짧게 말하면 :

1. 내 선호 는 복수
2. 예
3. 테이블 : * 보통 * 접두사가없는 것이 가장 좋습니다. 열 : 아니오
4. 테이블과 열 모두 : PascalCase.

동화:

(1) 해야 할 일. 당신은 매우 몇 가지가있다 한다 특정한 방식으로, 모든 시간을,하지만 몇 가지가있다.

• "[singularOfTableName] ID"형식을 사용 하여 기본 키 이름을 지정하십시오 . 즉, 테이블 이름이 Customer 또는 Customers 인지 여부에 상관없이 기본 키는 CustomerID 여야합니다 .
• 또한 외래 키 는 다른 테이블에서 일관되게 이름을 지정 해야합니다 . 이것을하지 않는 사람을 때리는 것이 합법적이어야합니다. 정의 된 외래 키 제약 조건이 종종 중요하지만 일관된 외래 키 이름 지정이 항상 중요하다는 것을 제출합니다.
• 데이터베이스에는 내부 규칙이 있어야합니다 . 이후 섹션에서 매우 유연하다는 것을 알 수 있지만 데이터베이스 이름 내 에서는 일관성이 있어야합니다. 고객을위한 테이블이 호출되는지 여부를 고객 또는 고객 이 동일한 데이터베이스를 통해 그것을 같은 방식으로 수행하는 것이보다 중요하다. 또한 밑줄을 사용하는 방법을 결정하기 위해 동전을 뒤집을 수 있지만 동일한 방식으로 밑줄을 사용해야합니다 . 이렇게하지 않으면 자존감이 낮은 나쁜 사람입니다.

(2) 당신이해야 할 일.

• 다른 테이블에서 동일한 종류의 데이터를 나타내는 필드의 이름은 동일 해야 합니다. 한 테이블에는 Zip이 있고 다른 테이블에는 ZipCode가 없습니다.
• 테이블 또는 열 이름에서 단어를 구분하려면 PascalCasing을 사용하십시오. camelCasing을 사용하는 것은 본질적으로 문제가되지는 않지만 관습이 아니며 재미있을 것입니다. 잠시 후 밑줄을 다룰 것입니다. (이전과 같이 ALLCAPS를 사용할 수 없습니다. OBNOXIOUSTABLE.ANNOYING_COLUMN은 20 년 전 DB2에서는 괜찮 았지만 지금은 아닙니다.)
• 단어를 인위적으로 줄이거 나 축약하지 마십시오. 짧고 혼란스러운 것보다 이름이 길고 명확하게하는 것이 좋습니다. 매우 짧은 이름은 더 어둡고 더 잔인한 시대의 이월입니다. Cus_AddRef. 그것은 무엇입니까? 양육권 주소 참조? 고객 추가 환불? 맞춤 주소 추천?

(3) 고려해야 할 사항.

• 테이블에 대해 복수의 이름을 가져야한다고 생각합니다. 일부는 단수로 생각합니다. 다른 곳의 주장을 읽으십시오. 그러나 열 이름은 단수 여야합니다. 복수 테이블 이름을 사용하더라도 다른 테이블의 조합을 나타내는 테이블은 단수 일 수 있습니다. 예를 들어, Promotions 및 Items 테이블 이있는 경우 프로모션 의 일부인 항목을 나타내는 테이블은 Promotions_Items 일 수 있지만 합법적으로 내가 생각하는 Promotion_Items 일 수도 있습니다 (일대 다 관계 반영).
• 일관되고 특정 목적으로 밑줄을 사용하십시오. PascalCasing을 사용하면 일반적인 테이블 이름 만 충분히 명확해야합니다. 단어를 구분하기 위해 밑줄이 필요하지 않습니다. 밑줄을 (a) 연관 테이블을 나타내거나 (b) 접두사로 저장하십시오. 다음 글 머리 기호에서 다룰 것입니다.
• 접두사는 좋지 않습니다. 그것은 일반적으로 가장하지 않습니다. 첫 번째 db 또는 두 번째 테이블에서는 일반적인 주제별 테이블 그룹화에 접두사를 사용하지 않는 것이 좋습니다. 테이블은 범주를 쉽게 맞추지 못하기 때문에 실제로 테이블을 찾기가 더 어려워 질 수 있습니다. 경험이 있으면 해보다 더 좋은 접두사 체계를 계획하고 적용 할 수 있습니다. 데이터 테이블이 tbl으로 시작한 구성 테이블, ctbl이있는 구성 테이블 , vew가있는 뷰 , proc의 sp 및 udf의 fn이 있는 DB에서 한 번 작업했습니다., 및 기타 몇 명; 그것은 꼼꼼하고 일관되게 적용되어 정상적으로 작동했습니다. 접두사를 필요로하는 유일한 이유는 어떤 이유로 같은 db에 상주하는 별도의 솔루션을 가지고있을 때입니다. 접두사를 붙이면 테이블을 그룹화하는 데 매우 도움이 될 수 있습니다. 접두사는 또한 임시 테이블과 같이 특별한 상황에 적합합니다.
• 열 접두사를 사용하는 경우는 거의 없습니다.

우리는 의견을 가지고 무게를 측정하기 때문에 :

테이블 이름은 복수 여야한다고 생각합니다. 테이블은 엔터티의 모음 (테이블)입니다. 각 행은 단일 엔터티를 나타내고 테이블은 컬렉션을 나타냅니다. 그래서 나는 Person 엔티티 People (또는 Person, 당신의 공상을 취하는 모든 것)의 테이블이라고 부를 것입니다.

쿼리에서 단 하나의 "엔티티 이름"을보고 싶은 사람들에게는 이것이 테이블 별칭을 사용하는 것입니다.

SELECT person.Name
FROM People person

LINQ의 "사람의 사람에서 사람을 선택하십시오. 이름"과 비슷합니다.

2, 3 및 4는 @Lars에 동의합니다.

나는 3 개의 DBA와 함께 데이터베이스 지원 팀에서 일하고 있으며 고려되는 옵션은 다음과 같습니다.

1. 모든 명명 표준은 표준이없는 것보다 낫습니다.
2. "하나의 진정한"표준은 없으며, 우리 모두 선호합니다
3. 표준이 이미있는 경우 사용하십시오. 다른 표준을 만들거나 기존 표준을 어지럽히 지 마십시오.

테이블에는 단수 이름을 사용합니다. 테이블 이름 앞에 시스템 이름 (또는 그 약어)이 붙습니다. 테이블을 논리적으로 그룹화하기 위해 접두사를 변경할 수 있으므로 시스템이 복잡한 경우에 유용합니다 (예 : reg_customer, reg_booking 및 regadmin_limits).

필드의 경우 필드 이름에 테이블의 접두사 / 암호 (예 : cust_address1)가 포함될 것으로 예상되며 표준 접미사 세트 (PK의 경우 _id, "code"의 경우 _cd, "name"의 경우 _nm)를 선호합니다. ", _nb"숫자 ", _dt"날짜 ").

Foriegn 키 필드의 이름은 기본 키 필드와 같아야합니다.

즉

SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id

새 프로젝트를 개발할 때 선호하는 모든 엔티티 이름, 접두사 및 머리 글자를 작성하고이 문서를 개발자에게 제공하는 것이 좋습니다. 그런 다음 새 테이블을 만들 때 테이블과 필드를 무엇이라고 "추측"하는 대신 문서를 참조 할 수 있습니다.

1. 아니요. 테이블은 해당 엔티티가 나타내는 이름을 따라야합니다. 사람이 아니라 사람이 기록 중 하나를 나타내는 사람을 참조하는 방법입니다.
2. 다시 같은 것. FirstName 열은 실제로 FirstNames라고해서는 안됩니다. 그것은 모두 당신이 열로 표현하고자하는 것에 달려 있습니다.
3. 아니.
4. 예. 명확성을 위해 사례를 작성하십시오. "FirstName"과 같은 열이 필요한 경우 케이싱을 사용하면 쉽게 읽을 수 있습니다.

확인. 그건 내 $ 0.02

나는 또한 규범 적이기보다는 지침이라는 점에서 ISO / IEC 11179 스타일 명명 규칙을 선호합니다.

Wikipedia의 데이터 요소 이름을 참조하십시오 .

"테이블은 엔티티의 콜렉션이며 콜렉션 이름 지정 지침을 따르십시오. 이상적으로는 단체 이름이 사용됩니다. 예 : 인사. 복수도 올바른 것 : 직원. 올바르지 않은 이름은 Employee, tblEmployee 및 EmployeeTable입니다."

항상 그렇듯이 규칙에는 예외가 있습니다. 예를 들어 항상 정확히 하나의 행을 가진 테이블은 구성 테이블과 같은 단일 이름으로 더 좋습니다. 일관성은 매우 중요합니다. 쇼핑에 컨벤션이 있는지 확인하고, 그렇다면 컨벤션이 있는지 확인하십시오. 마음에 들지 않으면 비즈니스 레인저가 아닌 비즈니스 사례를 변경하십시오.

나는 테이블이 복수인지의 여부는 모두 개인적인 취향의 문제이며 모범 사례는 없다는 주장을 항상 듣습니다. 나는 그것이 DBA가 아닌 프로그래머로서 사실이라고 생각하지 않습니다. 내가 아는 한, "단지 테이블 이름을 가짐으로써 코드에서 합법적 인 이득을 얻는 반면"테이블이 객체 컬렉션이기 때문에 나에게 의미가 있습니다. "이외의 테이블 이름을 복수화해야하는 합법적 인 이유는 없습니다. 예를 들면 다음과 같습니다.

1. 복수 모호성으로 인한 버그와 실수를 피합니다. 프로그래머는 철자 전문 지식으로 정확하게 알려져 있지 않으며 일부 단어를 혼동하는 것은 혼란스러워합니다. 예를 들어, 복수 단어는 'es'또는 's'로 끝나는가? 사람입니까, 사람입니까? 대규모 팀이있는 프로젝트에서 작업 할 때 문제가 될 수 있습니다. 예를 들어 팀 구성원이 잘못된 방법을 사용하여 자신이 만든 테이블을 복수화하는 인스턴스입니다. 이 테이블과 상호 작용할 때 액세스 할 수 없거나 수정하는 데 너무 오래 걸리는 코드에서 사용됩니다. 결과적으로 테이블을 사용할 때마다 철자를 잘못 입력해야합니다. 이것과 매우 비슷한 것이 나에게 일어났다. 모든 팀원이 정확하고 일관되게 쉽고 정확하게 사용할 수 있도록 오류없이 테이블 이름을 수정하거나 항상 테이블 이름을 찾아야하는 것이 좋습니다. 단일 버전은 팀 환경에서 처리하기가 훨씬 쉽습니다.

2. 단일 이름의 테이블 이름을 사용하고 기본 키에 테이블 이름을 접두어로 사용하면 기본 키에서 테이블 이름을 쉽게 결정하거나 그 반대로 코드만으로도 이점을 얻을 수 있습니다. 테이블 이름이 포함 된 변수를 부여하고 끝에 "Id"를 연결하면 추가 쿼리를 수행 할 필요없이 코드를 통해 테이블의 기본 키를 갖게됩니다. 또는 기본 키 끝에서 "Id"를 잘라내어 코드를 통해 테이블 ​​이름을 결정할 수 있습니다. 기본 키에 테이블 이름없이 "id"를 사용하면 코드를 통해 기본 키에서 테이블 이름을 결정할 수 없습니다. 또한 테이블 이름과 테이블 이름으로 PK 열 접두어를 복수화하는 대부분의 사람들은 PK에서 테이블 이름의 단일 버전 (예 : statuses 및 status_id)을 사용합니다.

3. 테이블 이름을 단수로 만들면 표 이름을 나타내는 클래스 이름과 일치시킬 수 있습니다. 다시 한 번, 이것은 코드를 단순화하고 테이블 이름 만 있으면 클래스를 인스턴스화하는 것과 같이 정말 깔끔한 작업을 수행 할 수 있습니다. 또한 코드를보다 일관성있게 만들어서 ...

4. 테이블 이름을 단수로 만들면 이름 지정 체계가 일관되고 체계적이며 모든 위치에서 유지 관리하기가 쉽습니다. 코드의 모든 인스턴스에서 열 이름, 클래스 이름 또는 테이블 이름에 관계없이 동일한 이름과 동일하다는 것을 알고 있습니다. 이를 통해 전역 검색을 수행하여 해당 데이터가 사용되는 모든 곳을 볼 수 있습니다. 테이블 이름을 복수화하면 해당 테이블 이름의 단일 버전 (기본 키에서 해당 클래스)이 사용되는 경우가 있습니다. 데이터가 복수이고 일부는 단수 인 경우가없는 것이 합리적입니다.

요약하면, 테이블 이름을 복수화하면 코드를 더 똑똑하고 다루기 쉽게 만드는 데있어 모든 이점을 잃게됩니다. 테이블 이름을 피할 수있는 오브젝트 또는 로컬 코드 이름으로 변환하기 위해 찾아보기 테이블 / 배열이 필요한 경우도 있습니다. 단수 테이블 이름은 처음에는 약간 이상하다고 생각되지만 복수 이름에 비해 상당한 이점을 제공하며 모범 사례라고 생각합니다.

우리의 선호 :

1. 테이블 이름이 복수 여야합니까?
   못. 컬렉션에 대한 인수는 의미가 있지만 테이블에 무엇을 포함할지 (0,1 또는 많은 항목) 알 수 없습니다. 복수 규칙은 불필요하게 명명을 복잡하게 만듭니다. 1 집, 2 집, 마우스 대 마우스, 사람 대 사람, 그리고 우리는 다른 언어를 보지 않았습니다.

   Update person set property = 'value'테이블의 각 사람에게 행동합니다.
   Select * from person where person.name = 'Greg'개인 행의 컬렉션 / 행 집합을 반환합니다.

2. 열 이름이 단수 여야합니까?
   정규화 규칙을 위반하는 경우를 제외하고 일반적으로 그렇습니다.

3. 테이블이나 열을 접두사로 사용해야합니까?
   대부분 플랫폼 환경 설정입니다. 테이블 이름 앞에 열을 추가하는 것이 좋습니다. 테이블 접두사는 없지만 접두사 뷰 (v_)와 stored_procedures (sp_ 또는 f_ (함수))를 수행합니다. 이는 실제로 뷰에서 계산 된 필드 인 v_person.age를 업데이트하려고하는 사람들에게 도움이됩니다 (어쨌든 업데이트 할 수 없음).

   키워드 충돌을 피할 수있는 좋은 방법이기도합니다 (delivery.from은 중단되지만 delivery_from은 그렇지 않습니다).

   코드를 더 장황하게 만들지 만 가독성을 높이는 데 도움이됩니다.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... 매우 읽기 쉽고 명확합니다. 그래도 손에서 벗어날 수 있습니다.

   customer.customer_customer_type_id

   고객과 customer_type 테이블 간의 관계를 나타내며 customer_type 테이블의 기본 키 (customer_type_id)를 나타내며 쿼리를 디버깅하는 동안 'customer_customer_type_id'가 표시되면 (고객 테이블)의 위치를 ​​즉시 알 수 있습니다.

   또는 customer_type과 customer_category 사이에 MM 관계가있는 경우 (특정 유형 만 특정 카테고리에 사용 가능)

   customer_category_customer_type_id

   ... 긴쪽에 약간 (!)입니다.

4. 항목 이름을 지정할 때 대소 문자를 사용해야합니까? 예-소문자 :). 밑줄이 있습니다. 이들은 매우 읽기 쉽고 크로스 플랫폼입니다. 위의 3과 함께도 의미가 있습니다.

   그러나 이것들의 대부분은 선호 사항입니다. -일관된 한, 그것을 읽어야하는 사람이라면 누구나 예측할 수 있어야합니다.

ISO 11179-5 : 명명 및 식별 원칙을 살펴보십시오. 여기에서 얻을 수 있습니다. http://metadata-standards.org/11179/#11179-5

내가 다시 여기에 대해 잠시 블로그 : ISO-11179 명명 규칙을

나는 이것이 게임에 늦었다는 것을 알고 있으며 질문은 이미 잘 대답되었지만 열 이름의 접두사에 관한 # 3에 대한 의견을 제시하고 싶습니다.

모든 열은 정의 된 테이블에 고유 한 접두어로 이름을 지정해야합니다.

예를 들어 "customer"와 "address"테이블이 주어지면 각각 "cust"와 "addr"의 접두사를 사용하십시오. "고객"에는 "cust_id", "cust_name"등이 포함됩니다. "주소"에는 "addr_id", "addr_cust_id"(고객에게 FK), "addr_street"등이 포함됩니다.

내가이 표준을 처음 받았을 때 나는 그 표준에 맞서 죽었습니다. 나는 그 아이디어를 싫어했다. 나는 여분의 타이핑과 여분의 아이디어를 참을 수 없었습니다. 이제 나는 다시는 가지 않을 정도로 충분한 경험을 가지고 있습니다.

이렇게하면 데이터베이스 스키마의 모든 열이 고유합니다. 이것에 대한 한 가지 주요 이점이 있습니다. 이에 대한 모든 주장보다 우선합니다 (물론 내 의견으로는).

전체 코드 기반을 검색하고 특정 열에 닿는 모든 코드 줄을 안정적으로 찾을 수 있습니다.

# 1의 이점은 엄청나게 크다. 열을 더 이상 사용하지 않고 스키마에서 열을 안전하게 제거하기 전에 어떤 파일을 업데이트해야하는지 정확히 알 수 있습니다. 열의 의미를 변경하고 리팩터링해야하는 코드를 정확히 알 수 있습니다. 또는 열의 데이터가 시스템의 특정 부분에서 사용되고 있는지 간단히 알 수 있습니다. 이것이 잠재적으로 거대한 프로젝트를 단순한 프로젝트로 전환 한 횟수 나 개발 작업에서 절약 한 시간을 셀 수는 없습니다.

그것에 대한 또 다른 비교적 작은 이점은 자체 조인을 수행 할 때 테이블 별칭 만 사용해야한다는 것입니다.

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

이것에 대한 나의 의견은 다음과 같습니다.

1) 아니요, 테이블 이름은 단수 여야합니다.

간단한 선택 ( select * from Orders)에는 적합하지만 OO에 해당하는 ( Orders x = new Orders) 에는 적합하지 않습니다 .

DB의 테이블은 실제로 해당 엔티티의 집합이며 set-logic을 사용하면 더 의미가 있습니다.

select Orders.*
from Orders inner join Products
    on Orders.Key = Products.Key

마지막 조인, 실제 조인 논리는 복수 테이블 이름과 혼동되는 것처럼 보입니다.

Matt가 제안한 것처럼 항상 별칭을 사용하는 것이 확실하지 않습니다.

2) 단지 1 개의 부동산 만 보유하므로 단수 여야합니다.

3) 컬럼 이름이 모호한 경우 (위에서와 같이 [Key]라는 컬럼이있는 경우) 테이블 이름 (또는 별명)이 충분히 구별 할 수는 없습니다. 쿼리를 빠르게 입력하고 간단하게 만들려면 접두사가 불필요한 복잡성을 가중시킵니다.

4) 원하는 것이 무엇이든 CapitalCase를 제안합니다.

나는 이것들에 대한 절대 지침이 하나도 없다고 생각합니다.

선택한 것이 무엇이든 응용 프로그램이나 DB에서 일관성이있는 한 실제로 중요하지 않다고 생각합니다.

내 의견으로는 :

1. 테이블 이름은 복수 여야합니다.
2. 열 이름은 단수 여야합니다.
3. 아니.
4. 테이블 이름과 열 이름 모두 CamelCase (나의 선호) 또는 밑줄로 구분됩니다.

그러나 언급 된 바와 같이, 모든 협약은 협약이없는 것보다 낫습니다. 어떤 방법을 선택하든 향후 수정 사항이 동일한 규칙을 따르도록 문서화하십시오.

각 질문에 대한 최선의 답변은 귀하와 귀하의 팀이 제공 할 것이라고 생각합니다. 이름 지정 규칙을 사용하는 것보다 이름 지정 규칙을 사용하는 것이 훨씬 더 중요합니다.

그것에 대한 정답이 없기 때문에 시간이 걸리지 만 너무 많은 것이 아니라 자신의 협약을 선택해야하며 여기 에 중요한 부분이 있습니다.

물론 표준에 대한 정보를 찾는 것이 좋습니다. 이것은 당신이 요구하는 것입니다. 그러나 당신이 얻을 수있는 다른 답변의 수에 대해 걱정하거나 걱정하지 마십시오. 더 나은 것으로 보이는 것을 선택하십시오.

만일을 위해, 여기 내 대답이 있습니다 :

1. 예. 테이블은 레코드 , 교사 또는 행위자 그룹입니다. 이므로 복수형입니다.
2. 예.
3. 나는 그들을 사용하지 않습니다.
4. 더 자주 사용하는 데이터베이스-Firebird는 모든 것을 대문자로 유지하므로 중요하지 않습니다. 어쨌든 프로그래밍 할 때 releaseYear 와 같이 읽기 쉬운 방식으로 이름을 씁니다 .

1. 사람들이 아닌 테이블 이름을 단수로 유지하십시오.
   2. 여기 동일
   3. 아니요. 처리 할 대상이 테이블 (tbl_) 또는 사용자 저장 프로 시저 (usp_)임을 나타내는 한 끔찍한 접두사를 보았습니다. 그 뒤에 데이터베이스 이름이옵니다 ...하지 마십시오!
   4. 예. 모든 테이블 이름을 PascalCase하는 경향이 있습니다.

명명 규칙을 통해 개발 팀은 프로젝트의 핵심에서 검색 가능성과 유지 관리 기능을 설계 할 수 있습니다.

좋은 명명 규칙은 진화하는 데 시간이 걸리지 만 일단 배치되면 팀은 공통 언어로 발전 할 수 있습니다. 좋은 명명 규칙은 프로젝트와 함께 유기적으로 성장합니다. 좋은 이름 지정 규칙은 소프트웨어 수명주기의 가장 길고 가장 중요한 단계 인 프로덕션의 서비스 관리 중 변경에 쉽게 대처할 수 있습니다.

내 대답은 다음과 같습니다.

1. 예, 테이블 이름은 일련의 거래 , 유가 증권 또는 상대방 을 지칭 할 때 복수 여야합니다. 을 .
2. 예.
3. 예. SQL 테이블은 tb_로 시작하고, 뷰는 vw_로 시작하고, 저장 프로시 저는 usp_로 시작하고, 트리거는 tg_로 시작하고 그 뒤에 데이터베이스 이름이옵니다.
4. 열 이름은 밑줄로 구분 된 소문자 여야합니다.

이름 지정은 어렵지만 모든 조직에는 이름을 지정할 수있는 사람이 있으며 모든 소프트웨어 팀에는 이름 지정 표준을 책임지고 sec_id , sec_value 및 security_id 와 같은 이름 지정 문제 가 프로젝트에 착수하기 전에 조기에 해결 되도록하는 사람이 있어야합니다. .

따라서 좋은 명명 규칙 및 표준의 기본 원칙은 무엇입니까?

• 클라이언트 및 솔루션 도메인의 언어 사용
• 설명하기
• 일관성을 유지하십시오
• 명확성, 반영 및 리팩토링
• 모든 사람에게 명확하지 않은 한 약어를 사용하지 마십시오
• SQL 예약 키워드를 열 이름으로 사용하지 마십시오

다음은 몇 가지 선택 사항을 제공하는 링크입니다. 부분적으로 정의 된 사양에 의존하지 않고 따를 수있는 간단한 사양을 찾고있었습니다.

http://justinsomnia.org/writings/naming_conventions.html

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

테이블 이름은 개체 집합을 나타내므로 항상 단수 여야합니다. 당신이 말한 것처럼 양 무리를 지정하거나 무리는 새 무리를 지정합니다. 복수가 필요 없습니다. 테이블 이름이 두 개의 이름으로 구성되고 이름 지정 규칙이 복수 인 경우 복수 이름이 첫 번째 단어인지 두 번째 단어인지 또는 둘 다 여야하는지 알기가 어렵습니다. 논리입니다 – objects.instance가 아니라 Object.instance입니다. 또는 TableNames.column (s)이 아닌 TableName.column. Microsoft SQL은 대소 문자를 구분하지 않으므로 대문자를 사용하는 경우 두 개 이상의 이름으로 구성된 테이블 또는 열 이름을 구분하기 위해 테이블 ​​이름을 쉽게 읽을 수 있습니다.

테이블 이름 : 실제 개체를 나타내는 단일 개체이므로 개체가 아닌 단일 개체 여야합니다.

열 이름 : 단수 여야하며 원자 값을 보유하고 정규화 이론을 확인합니다. 그러나 n 개의 동일한 유형의 속성이있는 경우 1, 2, ..., n 등으로 접미사를 붙여야합니다.

접두사 테이블 / 열 : 그것은 큰 주제이므로 나중에 논의 할 것입니다.

케이싱 : 낙타 케이스 여야합니다

내 친구 패트릭 카처 (Patrick Karcher )는 "당신이 외래 키를 다른 테이블에서 일관되게 명명해야합니다. 그렇지 않은 사람을 때리는 것이 합법적이어야합니다. 이 작업을 수행.". 내 친구 패트릭이 실수를 한 적이 없지만 나는 일반적으로 글을 쓰고 있습니다. 그들이 함께 당신을 이길 계획이라면 어떨까요? :)

파티에 늦었지만 열 접두사에 대해 2 센트를 추가하고 싶었습니다.

열 이름 자체가 전체 데이터베이스에서 고유하다는 사실을 기반으로 열에 table_column (또는 tableColumn) 명명 표준을 사용하는 데에는 두 가지 주요 인수가있는 것 같습니다.

1) 쿼리에서 항상 테이블 이름 및 / 또는 열 별칭을 지정할 필요는 없습니다.

2) 전체 코드에서 열 이름을 쉽게 검색 할 수 있습니다.

나는 두 가지 주장에 결함이 있다고 생각한다. 접두사를 사용하지 않고 두 가지 문제에 대한 솔루션은 쉽습니다. 내 제안은 다음과 같습니다.

항상 SQL에서 테이블 이름을 사용하십시오. 예를 들어, 열 대신 항상 table.column을 사용하십시오.

2) 이제 table_column 대신 table.column을 검색 할 수 있으므로 분명히 해결됩니다.

그러나 나는 당신이 비명 소리를들을 수 있습니다. 어떻게 해결됩니까? 1)? 이것을 피하는 것이 었습니다. 그렇습니다. 그러나 솔루션에는 끔찍한 결함이있었습니다. 왜? 접두사 솔루션은 다음과 같이 요약됩니다.
모호성이있을 때 table.column을 지정하지 않아도되도록 모든 열의 이름을 table_column!
그러나 이것은 이제부터 열을 지정할 때마다 항상 열 이름을 작성해야 함을 의미합니다. 그러나 어쨌든 그렇게해야한다면 항상 명시 적으로 table.column을 작성하는 것의 이점은 무엇입니까? 정확히, 이점은 없습니다. 입력하는 것과 정확히 동일한 문자 수입니다.

편집 : 예, 접두어로 열 이름을 지정하면 올바른 사용법이 적용되는 반면 내 접근 방식은 프로그래머에게 의존한다는 것을 알고 있습니다

필수 데이터베이스 이름 지정 규칙 (및 스타일) (자세한 설명은 여기를 클릭하십시오)

테이블 이름은 짧고 모호하지 않은 이름을 선택합니다. 한두 단어 만 사용하면 테이블을 쉽게 구별 할 수 있습니다. 테이블을 쉽게 검색 할 수있을뿐만 아니라 고유 한 필드 이름을 쉽게 지정할 수 있습니다. 이 컨벤션을 위해 대부분의 사람들은 실제로 복수 테이블 이름을 좋아하므로 입장을 부드럽게했습니다.) ... 위의 링크를 따르십시오.

테이블 이름은 단수입니다. 누군가와 주소 간의 현실을 모델링한다고 가정 해 봅시다. 예를 들어 데이터 모델을 읽는 경우 '각 사람이 0,1 또는 많은 주소에 살 수 있습니다.' 또는 '각 사람들은 0,1 또는 많은 주소에 살 수 있습니다.' 나는 사람들을 사람으로 바꾸지 말고 복수를 다루는 것이 더 쉽다고 생각한다. 또한 집단 명사는 단수형과 매우 유사합니다.

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

이것들은 내가 가르친 관습이지만, 개발 호스가 사용하는 모든 것에 적응해야합니다.

1. 복수형. 엔터티의 모음입니다.
2. 예. 이 속성은 엔터티의 단일 속성을 나타냅니다.
3. 예, 접두사 테이블 이름을 사용하면 모든 제약 조건 인덱스 및 테이블 별칭의 이름을 쉽게 추적 할 수 있습니다.
4. 테이블 및 열 이름의 경우 파스칼 케이스, 인덱스 및 제약 조건의 접두사 + ALL 한도.