데이터베이스, 테이블 및 열 이름 지정 규칙?

데이터베이스, 테이블 및 열 이름 지정 규칙?

문 닫았습니다.이 질문은의견에 입각한현재 답변을 받지 않고 있습니다.

---

이 질문을 개선하고 싶으십니까?이 게시물을 편집하여 사실과 인용으로 답변할 수 있도록 질문을 업데이트합니다.

10년 전에 문을 닫았습니다.

이 질문을 개선합니다.

데이터베이스를 설계할 때마다 데이터베이스에 항목 이름을 지정하는 가장 좋은 방법이 있는지 항상 고민합니다.저는 종종 다음과 같은 질문을 합니다.

1. 테이블 이름은 복수로 해야 합니까?
2. 열 이름은 단수여야 합니까?
3. 테이블이나 열 앞에 접두사를 붙여야 합니까?
4. 항목 이름을 지을 때 어떤 경우라도 사용해야 합니까?

데이터베이스의 항목 이름을 지정할 때 권장되는 지침이 있습니까?

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

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

1. 표의 단수 이름
2. 열에 대한 단수 이름
3. 테이블 접두사의 스키마 이름(예:스킴 이름.테이블 이름)
4. 파스칼 케이싱(일명 상부 낙타 케이스)

답변이 늦었지만, 간단히 말해서:

1. 복수의 테이블 이름:저의 취향은 복수입니다.
2. 단수 열 이름: 예
3. 접두사 테이블 또는 열:

• 표: *일반적으로* 접두사가 없는 것이 가장 좋습니다.
• 열:아니요.

4. 표와 열 모두 항목 이름을 지정할 때 PascalCase를 사용합니다.

정교화:

(1) 당신이 해야 할 일.매번 특정한 방법으로 해야 할 일은 매우 적지만, 몇 가지가 있습니다.

• [[singularOfTableName]]을(를) 사용하여 기본 키 이름 지정ID" 형식입니다.즉, 테이블 이름이 고객이든 고객이든 기본 키는 고객이어야 합니다.신분증.
• 또한 외부 키의 이름은 서로 다른 테이블에서 일관되게 지정해야 합니다.이것을 하지 않는 사람을 때리는 것은 합법적이어야 합니다.저는 정의된 외국 키 제약 조건이 종종 중요하지만 일관된 외국 키 명명은 항상 중요하다고 제출할 것입니다.
• 데이터베이스에 내부 규약이 있어야 합니다.나중에 섹션에서 제가 매우 유연하다는 것을 알게 되겠지만, 데이터베이스 이름 지정은 매우 일관성이 있어야 합니다.고객을 위한 테이블을 고객이라고 부르든 고객이라고 부르든 동일한 데이터베이스를 통해 동일한 방식으로 테이블을 수행하는 것보다 덜 중요합니다.그리고 동전을 뒤집어서 밑줄을 사용하는 방법을 결정할 수 있지만, 그 다음에는 같은 방법으로 밑줄을 계속 사용해야 합니다.이렇게 하지 않으면 자존감이 낮아야 할 나쁜 사람입니다.

(2) 당신이 해야 할 일.

• 다른 테이블에서 동일한 종류의 데이터를 나타내는 필드의 이름은 동일해야 합니다.한 테이블에는 우편번호가 없고 다른 테이블에는 우편번호가 없습니다.
• 테이블 또는 열 이름에서 단어를 구분하려면 PascalCasing을 사용합니다.낙타 케이싱을 사용하는 것은 본질적으로 문제가 되지는 않겠지만, 그것은 관습이 아니며 재미있어 보일 것입니다.잠시후에 밑줄을 다루겠습니다. (옛날처럼 ALLCAPS를 사용할 수 없습니다.불쾌할 수 있습니다.NOTRAY_COLUMN은 20년 전 DB2에서는 괜찮았지만 지금은 아닙니다.)
• 단어를 인위적으로 줄이거나 축약하지 마십시오.이름은 짧고 헷갈리는 것보다 길고 명확한 것이 더 좋습니다.아주 짧은 이름들은 더 어둡고 야만적인 시대로부터 오는 것입니다.Cus_AddRef.도대체 그게 뭐에요?보관 주소인 참조?고객 추가 환불?사용자 지정 주소 소개?

(3) 당신이 고려해야 할 것.

• 나는 정말로 당신이 테이블에 여러 개의 이름을 가져야 한다고 생각합니다. 어떤 사람들은 단수라고 생각합니다.다른 곳의 주장을 읽습니다.그러나 열 이름은 단수여야 합니다.테이블 이름을 여러 개 사용하더라도 다른 테이블의 조합을 나타내는 테이블은 단수일 수 있습니다.예를 들어, 프로모션 및 항목 테이블이 있는 경우 프로모션의 일부인 항목을 나타내는 테이블은 프로모션이 될 수 있습니다.아이템, 하지만 합법적으로 프로모션일 수도 있음_내가 생각하는 아이템(일대다 관계 반영)
• 밑줄을 특정 용도로 일관되게 사용합니다.파스칼케이싱을 사용하면 일반 테이블 이름이 충분히 명확해야 합니다. 단어를 구분하기 위해 밑줄이 필요하지 않습니다.밑줄을 저장하여 연관표를 나타내거나 접두사를 붙이기 위해 (a) 밑줄을 저장합니다. 다음 글에서 다룰 것입니다.
• 접두사는 좋지도 나쁘지도 않습니다.그것은 보통 최고가 아닙니다.당신의 첫번째 db나 두개의 db에서, 저는 표의 일반적인 주제 그룹화를 위해 접두사를 사용하는 것을 제안하지 않습니다.테이블은 카테고리에 쉽게 맞지 않게 되고 실제로 테이블을 찾기가 더 어려워질 수 있습니다.경험을 통해 해보다 해를 끼치는 접두사 계획을 계획하고 적용할 수 있습니다.데이터 테이블이 tbl로 시작되는 db, ctbl로 시작되는 config tables, views with views, proc's sp, udf's fn 등에서 작업한 적이 있는데 꼼꼼하고 일관성 있게 적용되어 잘 되었습니다.접두사가 필요한 유일한 경우는 어떤 이유에서인지 동일한 DB에 상주하는 개별 솔루션이 있을 때입니다. 접두사를 붙이면 테이블을 그룹화하는 데 매우 도움이 됩니다.눈에 띄고 싶은 임시 테이블과 같은 특수한 상황에서는 접두사를 붙여도 좋습니다.
• 열 앞에 붙는 경우는 거의 없습니다.

좋아요, 우리가 의견을 가지고 저울질렀어요.

테이블 이름은 복수로 해야 한다고 생각합니다.테이블은 엔터티의 집합(테이블)입니다.각 행은 단일 개체를 나타내고, 표는 집합을 나타냅니다.그래서 저는 '인물' 표를 '인물'(또는 '인물', 당신이 좋아하는 것이 무엇이든)이라고 부를 것입니다.

쿼리에서 단수의 "엔트리 이름"을 보기를 원하는 사람들을 위해 테이블 별칭을 사용합니다.

SELECT person.Name
FROM People person

린큐의 "사람들에게서 사람을 선택합니다.이름.

2, 3, 4에 대해서는 @Lars에 동의합니다.

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

1. 어떤 작명 기준이라도 없는 것보다는 낫습니다.
2. "하나의 진정한" 기준은 없습니다. 우리 모두는 각자의 선호를 가지고 있습니다.
3. 이미 표준이 마련되어 있는 경우 이를 사용합니다.다른 기준을 만들거나 기존 기준을 흐리게 해서는 안 됩니다.

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

필드의 경우 필드 이름에 테이블의 접두사/아크릴론(즉, cust_address1)이 포함되어야 하며 표준 접미사 집합(PK의 경우 _id, "코드"의 경우 _cd, "이름"의 경우 _nm, "숫자"의 경우 _nb, "날짜"의 경우 _dt)을 사용하는 것이 좋습니다.

Forigen key 필드의 이름은 Primary key 필드와 같아야 합니다.

예.

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 열의 이름을 FirstName이라고 부르면 안 됩니다.이 모든 것은 열로 무엇을 표현할 것인가에 달려 있습니다.
3. 아니요.
4. 네, 명확하게 설명해 주세요"FirstName"과 같은 열이 필요한 경우에는 케이싱을 사용하면 읽기가 쉬워집니다.

알겠습니다. 제 0.02달러입니다.

테이블의 다원화 여부는 모두 개인 취향의 문제이며 모범 사례가 없다는 주장을 늘 듣습니다.특히 DBA가 아닌 프로그래머로서는 사실이 아니라고 생각합니다.제가 알기로는 "객체의 집합체이기 때문에 이해가 되는 것일 뿐" 이외에 표명을 복수화할 정당한 이유가 없는 반면, 단수의 표명을 가짐으로써 코드상 정당한 이득이 있는 것으로 알고 있습니다.예를 들어,

1. 이것은 여러 가지 모호함으로 인한 버그와 실수를 방지합니다.프로그래머들은 맞춤법 전문성으로 정확히 알려져 있지 않고, 몇몇 단어들을 복수화하는 것은 혼란스럽습니다.예를 들어, 복수형 단어는 'es'로 끝나나요, 아니면 그냥 's'로 끝나나요?사람인가요, 사람인가요?대규모 팀과 함께 프로젝트를 진행할 경우, 이 문제가 문제가 될 수 있습니다.예를 들어, 팀원이 잘못된 방법을 사용하여 작성한 테이블을 복수화하는 경우입니다.이 테이블을 사용할 때 액세스할 수 없거나 수정하는 데 시간이 너무 오래 걸리는 코드로 사용됩니다.결과적으로 테이블을 사용할 때마다 철자를 잘못 적어야 한다는 것을 기억해야 합니다.이것과 아주 비슷한 일이 저에게 일어났습니다.팀의 모든 구성원이 정확하고 정확한 테이블 이름을 오류 없이 일관성 있고 쉽게 사용할 수 있거나 항상 테이블 이름을 검색해야 하는 경우가 많을수록 좋습니다.단일 버전은 팀 환경에서 처리하기가 훨씬 쉽습니다.

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

3. 테이블 이름을 단수로 만들 경우, 테이블 이름이 나타내는 클래스 이름과 일치하도록 할 수 있습니다.다시 한 번 말하지만, 이것은 코드를 단순화할 수 있고 테이블 이름만 가지고 클래스를 인스턴스화하는 것과 같은 정말 깔끔한 일을 할 수 있게 해줍니다.코드의 일관성을 더 높여줄 뿐이고 그래서...

4. 테이블 이름을 단수로 만들면 모든 위치에서 일관성 있고 체계적이며 유지보수가 용이합니다.열 이름이든 클래스 이름이든 테이블 이름이든 코드의 모든 경우에 정확한 이름이 동일하다는 것을 알고 있습니다.이렇게 하면 데이터가 사용되는 모든 곳을 확인하기 위해 전역 검색을 수행할 수 있습니다.테이블 이름을 복수화할 때 해당 테이블 이름의 단수 버전(기본 키에서 변환되는 클래스)을 사용하는 경우가 있습니다.데이터가 복수로 지칭되는 인스턴스와 단일 인스턴스로 지칭되는 인스턴스가 없는 것은 타당합니다.

요약하자면, 테이블 이름을 복수화하면 코드를 더 똑똑하고 쉽게 만들 수 있는 모든 이점을 잃게 됩니다.테이블 이름을 객체 또는 로컬 코드 이름으로 변환하기 위해 룩업 테이블/어레이가 있어야 하는 경우도 있을 수 있습니다.단수 테이블 이름은 처음에는 좀 이상하게 느껴질지 몰라도 복수화된 이름에 비해 상당한 이점을 제공하며 최선의 방법이라고 생각합니다.

또한 ISO/IEC 11179 스타일의 명명 규칙을 찬성하며, 규정적이라기 보다는 지침적인 것에 주목합니다.

위키백과의 데이터 요소 이름 참조:

"표는 개체 모음이며, 집합 명명 지침을 따릅니다.이상적으로, 집합적인 이름이 사용됩니다: 예를 들어, 인사.복수형도 맞습니다: 사원.잘못된 이름에는 다음과 같습니다.직원, tbl 직원 및 직원 테이블"

항상 그렇듯이 규칙에는 예외가 있습니다. 예를 들어 항상 정확히 하나의 행을 가지는 테이블은 단일 이름(예: 구성 테이블)과 함께 하는 것이 더 나을 수 있습니다.그리고 일관성은 무엇보다 중요합니다: 쇼핑을 할 때 컨벤션이 있는지 확인하고, 만약 그렇다면, 그것을 따르세요; 만약 마음에 들지 않으면, 단독 레인저가 아니라 비즈니스 케이스를 바꾸도록 하세요.

우리가 선호하는 것:

1. 테이블 이름은 복수로 해야 합니까?
   절대 아닙니다. 컬렉션이라는 주장은 일리가 있지만 테이블에 무엇이 포함될지(0,1 또는 많은 항목) 알 수 없습니다.복수의 규칙들은 명명을 불필요하게 복잡하게 만듭니다. 1 하우스, 2 하우스, 마우스 대 마우스, 사람 대 사람, 그리고 우리는 다른 언어들을 살펴보지도 않았습니다.

   Update person set property = 'value'테이블의 각 사람에게 작용합니다.
   Select * from person where person.name = 'Greg'사용자 행 집합/행 집합을 반환합니다.

2. 열 이름은 단수여야 합니까?
   정규화 규칙을 어기는 경우를 제외하고는 보통 그렇습니다.

3. 테이블이나 열 앞에 접두사를 붙여야 합니까?
   대부분은 플랫폼 선호입니다.열 앞에 테이블 이름을 붙여두는 것이 좋습니다.테이블을 접두사하지는 않지만 접두사 뷰(v_) 및 저장 프로시저(sp_ 또는 f_(함수))를 수행합니다.v_person.age를 업데이트하려는 사용자에게 도움이 됩니다. v_person.age는 보기에서 실제로 계산된 필드입니다(어쨌든 업데이트할 수 없습니다).

   키워드 충돌(delivery.from breaks, delivery_from)을 피할 수 있는 좋은 방법이기도 합니다.

   이것은 코드를 더 상세하게 만들지만 종종 가독성에 도움이 됩니다.

   bob = new person()
bob.person_name = 'Bob'
bob.person_dob = '1958-12-21'
   ... 매우 읽기 쉽고 명확합니다.하지만 이는 감당할 수 없는 일입니다.

   customer.customer_customer_type_id

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

   또는 customer_type과 customer_category 간에 M-M 관계가 있는 경우(특정 카테고리에서만 사용 가능)

   customer_category_customer_type_id

   ... 긴 쪽에 약간(!) 있습니다.

4. 항목 이름을 지을 때 어떤 경우라도 사용해야 합니까?예 - 소문자 :), 밑줄 포함.이것들은 매우 읽을 수 있고 교차 플랫폼입니다.위의 3개를 함께 사용하는 것도 합리적입니다.

   하지만 이런 것들은 대부분 선호하는 것들입니다. - 독자 분이 일관성을 유지하는 한, 이 책을 읽어야 하는 사람이라면 누구에게나 예측 가능합니다.

ISO 11179-5: 이름 지정 및 식별 원칙 여기에서 확인할 수 있습니다: http://metadata-standards.org/11179/ #11179-5

얼마 전에 블로그에 올린 적이 있습니다. ISO-11179 Naming Conventions

게임이 늦었다는 것을 알고 있고, 질문은 이미 아주 잘 답했지만, 칼럼 이름의 접두사와 관련하여 #3에 대한 제 의견을 말씀드리고 싶습니다.

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

예: 표 "customer"와 "address"가 주어졌을 때, 각각 "cust"와 "addr"의 접두사를 사용해 보겠습니다."customer"는 "cust_id", "cust_name" 등을 포함합니다."address"는 "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

그 마지막 줄, 조인의 실제 논리는 복수의 테이블 이름과 혼동되어 보입니다.

저는 항상 가명을 사용하는 것에 대해 확신이 서지 않습니다. (맷이 제안한 것처럼).

2) 그들은 하나의 속성만 보유하고 있으므로 단수여야 합니다.

3) 열 이름이 모호할 경우(위에서 둘 다 [Key]라는 열이 있는 경우) 테이블의 이름(또는 별칭)은 충분히 잘 구분할 수 있습니다.쿼리를 빠르게 입력하고 단순하게 입력하려는 경우 접두사를 사용하면 불필요한 복잡성이 추가됩니다.

4) 당신이 원하는게 뭐든 간에 캐피털 케이스는

이 중 어떤 것에도 절대적인 지침이 있다고 생각하지 않습니다.

애플리케이션이나 DB에서 선택하는 것이 일관성이 있다면 별로 중요하지 않다고 생각합니다.

제 의견으로는:

1. 테이블 이름은 복수여야 합니다.
2. 열 이름은 단수여야 합니다.
3. 아니요.
4. 테이블 이름과 열 이름 모두에 대해 CamelCase(기본 설정) 또는 undercore_separated입니다.

그러나 이미 언급했듯이, 어떤 컨벤션이라도 컨벤션이 없는 것보다는 낫습니다.선택 방법에 상관없이 문서화하여 향후 수정사항이 동일한 규칙을 따르도록 합니다.

그 각각의 질문에 대한 최선의 답변은 당신과 당신의 팀이 할 것이라고 생각합니다.명명 규칙이 정확히 어떤 것인지 보다 명명 규칙을 갖는 것이 훨씬 더 중요합니다.

그에 대한 올바른 답은 없으므로, 시간을 갖고 (너무 많이는 아니지만) 자신만의 관습을 선택해야 하며, 여기에 중요한 부분이를 고수해야 합니다.

물론 여러분이 묻고 있는 것인 표준에 대한 정보를 찾는 것은 좋지만, 여러분이 얻을 수 있는 다양한 대답의 수에 대해 걱정하거나 걱정하지 마세요: 여러분에게 더 나은 것으로 보이는 것을 선택하세요.

혹시 모르니 제 대답은 다음과 같습니다.

1. 네, 테이블이란 음반이나 선생님, 배우들로 구성된 집합체를..복수형.
2. 네.
3. 안 써요.
4. 제가 더 자주 사용하는 데이터베이스인 파이어버드는 모든 것을 대문자로 저장하므로 상관없습니다.어쨌든 제가 프로그래밍을 할 때는 Release Year처럼 읽기 쉽게 이름을 씁니다.

1. 테이블 이름을 사람이 아닌 사람을 단수로 유지해야 합니다.
   2. 저도 마찬가지에요.
   3. 아니요. 끔찍한 접두사를 봤는데, 테이블(tbl_)이나 사용자 스토어 절차(usp_)를 다루고 있다고까지 했습니다.데이터베이스 이름 뒤에...하지 마!
   4. 네. 저는 파스칼 케이스를 이용합니다. 제 테이블 이름은 모두

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

좋은 명명 규칙은 진화하는 데 시간이 걸리지만 일단 실행되면 팀이 공통 언어를 사용하여 앞으로 나아갈 수 있습니다.좋은 명명 규칙은 프로젝트와 함께 유기적으로 성장합니다.좋은 명명 규칙은 소프트웨어 라이프사이클의 가장 길고 가장 중요한 단계인 프로덕션의 서비스 관리 동안의 변화에 쉽게 대처할 수 있습니다.

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

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

테이블 이름은 개체 집합을 나타내므로 항상 단수여야 합니다.여러분이 말하는 양떼나 떼는 새떼를 가리킵니다.복수는 필요 없습니다.표 이름이 두 개의 이름으로 구성되어 있고 명명 규칙이 복수일 때 복수의 이름이 첫 번째 단어인지 두 번째 단어인지 아니면 둘 다인지 알 수 없습니다.논리입니다 – Object.instance, object.instance가 아닙니다.또는 TableName.column이 아니라 TableName.column입니다.Microsoft SQL은 대소문자를 구분하지 않으므로 대문자를 사용하는 경우 테이블 이름을 읽기 쉬우며 둘 이상의 이름으로 구성된 테이블 또는 열 이름을 구분할 수 있습니다.

테이블 이름:개체가 아닌 실제 세계의 개체를 나타내는 단일 개체이기 때문에 단일 개체여야 합니다.

열 이름:그것은 오직 그것이 원자 값을 보유할 것이고 정규화 이론을 확인할 것이라는 것을 전달할 때에만 단수여야 합니다.그러나 동일한 유형의 속성이 n개인 경우에는 1, 2, ..., n 등으로 접미사를 붙여야 합니다.

표 / 열 접두사:그것은 엄청난 주제입니다, 나중에 논의하겠습니다.

케이스: 카멜 케이스여야 합니다.

저의 친구 패트릭 카처(Patrick Karcher)는 "•또한 외국어 키는 서로 다른 표에 일관되게 이름을 붙여야 합니다.이렇게 하지 않는 사람을 때리는 것은 합법적이어야 합니다."친구 패트릭이 이런 실수를 한 적은 없지만, 전반적으로 글을 쓰고 있습니다.만약 그들이 함께 이것 때문에 당신을 이길 계획이라면요? :)

파티에 매우 늦었지만 나는 여전히 칼럼 접두사에 대한 나의 2센트를 추가하고 싶었습니다.

열 이름 자체가 전체 데이터베이스에서 고유하다는 사실에 근거하여 열에 대해 table_column(또는 tableColumn) 명명 표준을 사용하는 데는 두 가지 주요 논거가 있는 것 같습니다.

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

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

저는 두 주장 모두 결함이 있다고 생각합니다.접두사를 사용하지 않고 두 가지 문제를 모두 해결하는 것은 쉽습니다.제 제안은 이렇습니다.

SQL에서 항상 테이블 이름을 사용합니다. 예를 들어, 항상 컬럼 대신 table.column을 사용합니다.

이제 table_column 대신 table.column을 검색하면 되기 때문에 2)를 해결할 수 있습니다.

하지만 비명소리가 들리는데 어떻게 해결하나요 1)정확히 이것을 피하는 것이었습니다.네, 그렇습니다. 하지만 해결책이 끔찍할 정도로 결함이 많았습니다. 왜죠?접두사 솔루션은 다음과 같이 요약됩니다.
모호성이 있을 때 table.column을 지정할 필요가 없도록 모든 열 이름을 table_column으로 지정합니다!
그러나 이제부터는 열을 지정할 때마다 항상 열 이름을 써야 합니다.하지만 어쨌든 그렇게 해야 한다면, 항상 명확하게 table.column을 쓰는 것이 어떤 이점이 있습니까?맞아요, 혜택은 없어요, 정확히 입력할 글자 수와 같아요.

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

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

테이블 이름은 짧고 모호하지 않은 이름을 선택합니다. 한 두 단어 이하의 단어를 사용하는 구별된 테이블은 고유한 필드 이름의 명명을 용이하게 할 뿐만 아니라 조회 및 연결 테이블은 테이블에 결코 복수가 아닌 단수 이름을 부여합니다. (업데이트: 나는 여전히 이 관례에 주어진 이유에 동의하지만, 대부분의 사람들은 정말로 복수의 테이블 이름을 좋아합니다.그래서 입장을 누그러뜨렸습니다).위의 링크를 따라주시기 바랍니다.

테이블 이름은 단수입니다.당신이 누군가와 그들의 주소 사이의 관계를 모델링했다고 가정해 보겠습니다.예를 들어, 데이터 모델을 읽는 경우 '각 사람은 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. 테이블 및 열 이름은 Pascal Case, 인덱스 및 제약 조건은 접두사 + ALL 캡.

언급URL : https://stackoverflow.com/questions/7662/database-table-and-column-naming-conventions