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




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

테이블 이름 : 그것은 단수이어야합니다. 단 하나의 객체가 아니라 실세계 객체를 나타내는 단일 실체입니다.

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

Prefixing Tables / Columns : 그것은 거대한 주제이며, 나중에 논의 할 것입니다.

케이싱 : 카멜 케이스 야.

내 친구 패트릭 케처 (Patrick Karcher )는 다음과 같이 누군가에게 불쾌감을 줄 수있는 어떤 것도 쓰지 말 것을 요청했다. "또한, 외래 키는 다른 테이블에서 일관되게 이름을 붙여야하며 그렇지 않은 사람을 때리는 것이 합법적이어야합니다 이 작업을 수행.". 나는이 실수를 내 친구 Patrick에게 한 적이 없지만 일반적으로 글을 쓰고있다. 그들이 함께 당신을 이길 계획이라면? :)

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

  1. 테이블 이름은 복수형이어야합니까?
  2. 열 이름이 유일해야합니까?
  3. 테이블이나 컬럼의 접두어를 붙이면 안 될까요?
  4. 항목 이름을 지정하는 데 어떤 사례를 사용해야합니까?

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


테이블 이름은 개체 집합을 나타내므로 항상 단일 항목이어야합니다. 당신이 무리에게 양떼를 지명하라고 말하거나 무리를 지어 새 무리를 지명하십시오. 복수가 필요 없습니다. 테이블 이름이 두 개의 이름으로 구성되고 명명 규칙이 복수 인 경우, 복수의 이름이 첫 번째 단어인지 두 번째 단어인지 또는 두 가지 모두인지는 알 수 없습니다. 그것은 논리입니다 - Object.instance가 아니라 객체. 인스턴스. 또는 TableName.column이 아니라 TableName.column. Microsoft SQL은 대소 문자를 구분하지 않으므로 두 개 이상의 이름으로 구성된 테이블이나 열 이름을 구분하려면 대문자를 사용하는 경우 테이블 이름을 읽는 것이 더 쉽습니다.



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

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

테이블 이름은 하나 또는 두 단어 이상을 사용하지 않고 짧고 모호하지 않은 이름을 선택합니다. 구별 테이블은 쉽게 고유 한 필드 이름의 이름 지정을 용이하게하며 조회 및 연결 테이블은 테이블에 단 복수 이름을 부여합니다 (업데이트 : 여전히 주어진 이유에 동의 함). 이 대회에서,하지만 대부분의 사람들은 정말 복수형 테이블 이름을 좋아해요. 그래서 저는 제 입장을 부드럽게했습니다.) ... 위의 링크를 따라주세요.



--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. 파스칼 테이블과 컬럼 이름의 경우, 접두사 + 인덱스와 제약 조건의 경우 모두 대문자.

늦게 대답하지만 짧지 만 :

  1. 나의 선호도 는 복수형이다.
  2. 테이블 : * 보통 * 아무 접두사도 최상이 아닙니다. : 아니요.
  3. 테이블과 컬럼 모두 : PascalCase.

동화:

(1) 당신이해야 할 일. 매번 어떤 방법으로 해야 할 일이 거의 없지만 몇 가지가 있습니다.

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

(2) 당신이해야 할 일.

  • 서로 다른 테이블에있는 동일한 종류의 데이터를 나타내는 필드의 이름은 동일 해야 합니다. 한 테이블에는 Zip을, 다른 테이블에는 ZipCode를 사용하지 마십시오.
  • 표나 열 이름에서 단어를 분리하려면 PascalCasing을 사용하십시오. 낙타를 사용하는 것은 본질적으로 문제가되지 않지만 관습이 아니기 때문에 재미있을 것입니다. 잠시 후 밑줄을 다룰 것입니다. (옛날처럼 ALLCAPS를 사용할 수 없습니다. OBNOXIOUSTABLE.ANNOYING_COLUMN은 20 년 전 DB2에서 괜찮 았지만 지금은 아닙니다.)
  • 예술적으로 단어를 줄이거 나 생략하지 마십시오. 짧고 혼란스러운 이름보다 길고 명료하게하는 것이 좋습니다. 매우 짧은 이름은 더 어둡고 더 잔인한 시대의 지배자입니다. Cus_AddRef. 지구상에 뭐야? 관리인 수취인 참조? 고객 추가 환불? 맞춤 주소 추천?

(3) 고려해야 할 사항.

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

  1. 확실히 테이블 이름을 단수로 유지하고, 사람이 아닌 사람들을 유지하십시오.
    1. 같아요.
    2. 아니요. 나는 끔찍한 접두어를 보았습니다. 다루는 것이 테이블 (tbl_) 또는 사용자 저장소 프로 시저 (usp_)인지를 설명하기까지했습니다. 다음에 데이터베이스 이름이옵니다 ...하지 마십시오!
    3. 예. 나는 모든 테이블 이름을 PascalCase하는 경향이있다.

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

AdventureWorks 예제에서는 데이터베이스 개체의 조직에 대한 스키마 이름을 사용하는 매우 명확하고 일관된 명명 규칙을 사용합니다.

  1. 테이블의 단수 이름
  2. 기둥의 단수 이름
  3. 테이블 접두사의 스키마 이름 (예 : SchemeName.TableName)
  4. 파스칼 케이스 (일명 상단 카멜 케이스)

우리가 의견을 내고 있기 때문에 좋습니다.

나는 테이블 이름이 복수형이어야한다고 생각한다. 표는 항목의 모음 (표)입니다. 각 행은 단일 엔티티를 나타내고 테이블은 콜렉션을 나타냅니다. 그래서 저는 Person 엔티티 People (또는 Persons, 무엇이든 상관 없습니다)의 테이블을 호출 할 것입니다.

쿼리에서 단 하나의 "엔티티 이름"을보고 싶은 사람들은 다음과 같이 테이블 별명을 사용합니다.

SELECT person.Name
FROM People person

LINQ의 "people select person.Name"같은 사람.

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


나는 표가 복수화되어 있는지의 여부가 모두 개인 취향의 문제이며 모범 사례가 없다는 주장을 항상 듣는다. 나는 이것이 사실이라고 믿지 않습니다. 특히 DBA와는 반대로 프로그래머로서 말이죠. 필자가 알고있는 한 "테이블은 객체의 모음이기 때문에 나에게 맞는 것"이 ​​아닌 표 이름을 복수로 표기하는 합법적 인 이유는 없지만 단일 테이블 이름을 사용함으로써 코드에서 합법적 인 이득이 있습니다. 예 :

  1. 복수의 모호성으로 인한 버그 및 실수를 방지합니다. 프로그래머는 맞춤법 전문 지식으로 정확하게 알려지지 않았으며 일부 단어를 복수화하는 것은 혼란 스럽습니다. 예를 들어 복수 단어가 'es'또는 's'에 끝나나요? 그것은 사람입니까? 사람들입니까? 대규모 팀과 함께 프로젝트를 수행 할 때 문제가 될 수 있습니다. 예를 들어, 팀원이 잘못된 방법을 사용하여 그가 만든 테이블을 복수화하는 경우를 예로들 수 있습니다. 이 테이블과 상호 작용할 때까지는 코드에 액세스 할 권한이 없거나 수정하는 데 오랜 시간이 걸릴 것입니다. 결과적으로 테이블을 사용할 때마다 철자를 틀리게 기억해야합니다. 이것과 비슷한 것이 나에게 일어났다. 팀의 모든 구성원이 정확하고 정확한 표 이름을 오류없이 지속적으로 사용하거나 테이블 이름을 항상 찾아야하는 것이 더 쉬울수록 좋습니다. 단수 버전은 팀 환경에서 다루기가 훨씬 쉽습니다.

  2. 테이블 이름의 단일 버전을 사용하고 기본 키에 테이블 이름 접두사를 사용하면 코드 만 사용하여 기본 키에서 테이블 이름을 쉽게 결정할 수 있습니다. 테이블 이름이있는 변수를 지정하고 끝에 "Id"를 연결하면 추가 쿼리를 수행 할 필요없이 코드를 통해 테이블의 기본 키를 갖게됩니다. 또는 코드를 통해 테이블 ​​이름을 결정하기 위해 기본 키의 끝에서 "Id"를 잘라낼 수 있습니다. 기본 키의 테이블 이름없이 "id"를 사용하면 코드를 통해 기본 키의 테이블 이름을 결정할 수 없습니다. 또한 테이블 이름을 복수로하고 테이블 이름이있는 PK 열의 접두어를 사용하는 대부분의 사용자는 PK에서 테이블 이름의 단수 버전 (예 : status 및 statusId)을 사용하므로이 작업을 전혀 수행 할 수 없습니다.

  3. 테이블 이름을 단수로 만들면, 그들이 나타내는 클래스 이름과 일치시킬 수 있습니다. 다시 한번 말하지만, 이것은 코드를 단순화하고 테이블 이름 외에는 아무 것도하지 않아도 클래스를 인스턴스화하는 것과 같이 정말로 깔끔한 작업을 수행 할 수있게 해줍니다. 또한 코드의 일관성을 유지시켜 주므로 ...

  4. 테이블 이름을 단수로 만들면 이름 지정 체계가 모든 위치에서 일관되고 체계적이며 유지 관리가 쉽습니다. 코드의 모든 인스턴스에서 열 이름이든 클래스 이름이든 테이블 이름이든 정확히 동일한 이름입니다. 이를 통해 글로벌 검색을 통해 데이터가 사용되는 모든 곳을 볼 수 있습니다. 테이블 이름을 복수화하면 해당 테이블 이름의 단일 버전 (기본 키로 바뀌는 클래스)을 사용할 수 있습니다. 데이터가 복수형이고 일부 인스턴스가 단수 인 인스턴스가없는 것은 의미가 있습니다.

요약하면, 테이블 이름을 복수화하면 코드를 더 똑똑하고 쉽게 처리 할 수있는 모든 이점을 잃게됩니다. 테이블 이름을 피할 수있는 객체 또는 로컬 코드 이름으로 변환하기 위해 조회 테이블 / 배열을 가져야하는 경우도있을 수 있습니다. 단수의 테이블 이름은 처음에는 조금 이상하게 느껴질 지 모르지만 복수화 된 이름보다 중요한 이점을 제공하며 최선의 방법이라고 생각합니다.


데이터베이스 지원팀에서 3 명의 DBA와 함께 일하면서 고려해야 할 옵션은 다음과 같습니다.

  1. 모든 명명 표준은 표준보다 우수합니다.
  2. "하나의 진정한"표준은 없습니다. 우리 모두는 선호도를 가지고 있습니다.
  3. 이미 표준이있는 경우 사용하십시오. 다른 표준이나 진흙 투성이의 기존 표준을 만들지 마십시오.

우리는 테이블에 대해 단일 이름을 사용합니다. 테이블에는 시스템 (또는 그 약어)의 이름이 붙는 경향이 있습니다. 이것은 테이블이 논리적으로 함께 그룹화되도록 접두사를 변경할 수 있기 때문에 시스템이 복잡 할 때 유용합니다 (예 : reg_customer, reg_booking 및 regadmin_limits).

필드의 경우 필드 이름에 테이블의 접두어 / acryonm (예 : 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

새로운 프로젝트를 개발할 때 선호하는 모든 엔티티 이름, 접두사 및 두문자어를 작성하고이 문서를 개발자에게 제공하는 것이 좋습니다. 그런 다음 새 테이블을 만들 때 테이블과 필드를 호출해야하는 것을 "추측"하기보다는 문서를 참조 할 수 있습니다.


나는 이것이 게임에 늦었다는 것을 알고 있으며, 이미 질문에 대한 답변은 잘되어 있지만 컬럼 이름의 접두사와 관련하여 # 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%';


또한 ISO / IEC 11179 스타일 명명 규칙에 찬성합니다. 규범 적이기보다는 지침임을 지적합니다.

Wikipedia의 데이터 요소 이름 참조 :

"테이블은 엔터티의 컬렉션이며 컬렉션 명명 지침을 따르는 것이 가장 이상적으로 집합 이름이 사용됩니다 (예 : Personnel). Plural도 올바름 : Employees, Incorrect 이름은 Employee, tblEmployee 및 EmployeeTable입니다."

언제나 그렇듯이 규칙에는 예외가 있습니다. 예를 들어, 항상 정확히 하나의 행을 가진 테이블은 구성 테이블과 같이 단일 이름으로 더 나을 수 있습니다. 그리고 일관성이 가장 중요합니다 : 당신이 쇼핑하는 것이 컨벤션을 가지고 있는지 확인하십시오. 당신이 그것을 좋아하지 않는다면 외로운 레인저가되기보다는 바뀐 비즈니스 사례를하십시오.


표 이름은 단수입니다. 누군가와 주소 사이의 관계를 모델링했다고합시다. 예를 들어 데이터 모델을 읽는 경우 '각 사람은 0,1 또는 여러 주소로 살 수 있습니다.' 또는 '각 사람들은 0,1 또는 여러 주소에서 살 수 있습니다.' 나는 사람들을 사람으로 표현해야하는 것보다 주소를 복수화하는 것이 더 쉽다고 생각합니다. 더하기 집합 명사는 단수 버전에 상당히 자주 혼란 스럽습니다.


내 의견으로는 :

  1. 테이블 이름은 복수형이어야합니다.
  2. 열 이름은 단수이어야합니다.
  3. 아니.
  4. CamelCase (선호) 또는 테이블 이름과 열 이름 모두에 대해 underscore_separated.

그러나 언급 한 바와 같이 어떠한 관습도 관례를 따르는 것보다 낫습니다. 아무리 당신이 그것을 선택하더라도, 미래의 수정이 동일한 규칙을 따르도록 문서화하십시오.


파티에 아주 늦었지만 열 접두어에 대한 내 두 센트를 추가하고 싶었습니다.

column에 대해 table_column (또는 tableColumn) 명명 표준을 사용하는 데는 두 가지 주된 주장이 있습니다. 둘 다 열 이름 자체가 전체 데이터베이스에서 고유 할 것이라는 사실에 기반합니다.

1) 쿼리에서 테이블 이름 및 / 또는 열 별칭을 항상 지정하지 않아도됩니다.

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

나는 두 주장 모두에 결함이 있다고 생각한다. 접두사를 사용하지 않고 두 가지 문제를 해결할 수 있습니다. 내 제안은 다음과 같습니다.

항상 SQL에서 테이블 이름을 사용하십시오. 예 : 항상 column 대신 table.column을 사용하십시오.

table_column 대신 table.column을 검색하면되므로 2)를 분명히 해결합니다.

하지만 비명 소리가 들리지만 어떻게 해결하나요? 정확히 이것을 피하는 것이 었습니다. 예, 그렇습니다. 그러나 해결책은 끔찍하게 결함이있었습니다. 왜? 글쎄, 접두어 솔루션은 다음과 같이 요약됩니다.
모호함이있을 때 table.column을 지정하지 않으려면 모든 열의 이름을 table_column으로 지정하십시오!
하지만 지금부터는 열을 지정할 때마다 항상 열 이름을 써야합니다. 그러나 어쨌든 그렇게해야한다면, 항상 명시 적으로 table.column을 작성하는 것보다 어떤 이점이 있습니까? 정확히, 아무런 이점도 없습니다. 입력하는 문자 수와 정확히 같습니다.

편집 : 예, 전 접두사로 열의 이름을 지정하면 정확한 사용법을 적용한다는 것을 알고 있습니다. 그러나 필자의 접근 방식은 프로그래머에 달려 있습니다.


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

좋은 명명 규칙은 진화하는 데 시간이 걸리지 만 팀이 완성되면 공통 언어로 진행할 수 있습니다. 좋은 명명 규칙은 프로젝트와 함께 유기적으로 커집니다. 좋은 명명 규칙은 소프트웨어 수명주기의 가장 길고 중요한 단계 인 생산 관리에서의 서비스 관리에 대한 변경 사항을 쉽게 해결합니다.

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

  1. 네, 예를 들어, 거래 , 증권 또는 거래 상대방 을 가리키는 테이블 이름은 복수형이어야합니다.
  2. 예.
  3. 예. SQL 테이블에는 tb_ 접두어가 붙고, 뷰에는 접두어 vw_가 붙고, 저장 프로 시저에는 usp_ 접두어가 붙고 트리거에는 접두사 tg_와 데이터베이스 이름이 붙습니다.
  4. 열 이름은 밑줄로 구분하여 소문자로 구분해야합니다.

이름 지정은 어렵지만 모든 조직에는 이름을 지정할 수있는 사람이 있으며 모든 소프트웨어 팀에서 이름 지정 표준을 담당하고 sec_id , sec_valuesecurity_id 와 같은 이름 지정 문제가 프로젝트에 구워지기 일찍 해결되도록해야합니다. .

그렇다면 훌륭한 명명 규칙 및 표준의 기본 원칙은 무엇입니까?

  • 클라이언트와 솔루션 도메인의 언어 사용
  • 설명 적이어야한다.
  • 일관성있게
  • 모호성 제거, 반영 및 리팩토링
  • 모든 사람에게 명확하지 않으면 약어를 사용하지 마십시오.
  • SQL 예약 키워드를 열 이름으로 사용하지 마십시오.




naming-conventions