database - 네이밍 - 데이터베이스, 테이블 및 열 명명 규칙?




데이터 베이스 네이밍 룰 (16)

  1. 사람들이 아닌 테이블 이름을 단수로 유지하십시오.
    1. 여기 동일
    2. 아니요. 테이블 (tbl_) 또는 사용자 저장 절차 (usp_)가 무엇인지 다루기까지 끔찍한 접두사를 보았습니다. 그 뒤에 데이터베이스 이름이옵니다 ...하지 마십시오!
    3. 예. 모든 테이블 이름을 PascalCase하는 경향이 있습니다.

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

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

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


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

승인. 그건 내 $ 0.02


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

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

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

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

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

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

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

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

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

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

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

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


나는 이것이 게임에 늦었다는 것을 알고 있으며 질문은 이미 잘 대답했지만 열 이름의 접두사에 관한 # 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. 테이블 이름은 복수 여야합니다.
  2. 열 이름은 단수 여야합니다.
  3. 아니.
  4. 테이블 이름과 열 이름 모두 CamelCase (나의 선호) 또는 밑줄로 구분됩니다.

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



여기에 늦게 대답하지만 간단히 말하면 :

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

동화:

(1) 해야 할 일. 매번 특정 방식으로 수행 해야 할 작업은 거의 없지만 몇 가지가 있습니다.

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

(2) 당신이해야 할 일.

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

(3) 고려해야 할 사항.

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

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

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

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

SELECT person.Name
FROM People person

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

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


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

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) 열 이름이 모호한 경우 (위와 같이 둘 다 [키]라는 열이있는 경우) 테이블 이름 (또는 별명)으로 충분히 구분할 수 있습니다. 쿼리를 빠르게 입력하고 간단하게 만들려면 접두사가 불필요한 복잡성을 가중시킵니다.

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

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

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


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


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

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


테이블 이름 : 객체가 아닌 실제 객체를 나타내는 단일 엔티티이므로 단일형이어야합니다.

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

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

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

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



--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 한도.

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




naming-conventions