공식 PostgreSQL 대문자 표기 규칙 [닫기]


14

DB, 테이블 및 필드 이름의 대문자에 관한 공식 PostreSQL 규칙이 있습니까?

공식 사이트 는 소문자와 _단어 분리를 제안하며이 정책이 공식적인지 궁금합니다.

CREATE TABLE films (
    code        char(5) CONSTRAINT firstkey PRIMARY KEY,
    title       varchar(40) NOT NULL,
    did         integer NOT NULL,
    date_prod   date,
    kind        varchar(10),
    len         interval hour to minute
);

답변:


20

나는 기본적으로 Verace의 의견을 반영하고 이것을 반 공식으로 만들 것입니다.

모든 상황을 다루는 모범 사례 는 없습니다 . 다음 내용은 다음과 같은 가정을합니다 (이 작업을 수행하지 않은 경우 수행 할 작업).

  • 당신은 이미 당신의 팀과 이것에 대해 토론했습니다 (자기 일하는 사람들은 종종 마음을 구성해야합니다)
  • 이미 팀에 SQL에 대한 공식화 된 스타일 정의가 없습니다 (그렇지 않으면 우리에게 묻지 않을 것입니다)
  • 코드에 대해 공식화 된 스타일 정의가 없습니다 (다른 언어에 대해 이미 설정된 동일한 기본 규칙을 따르고 스타일을 공식화하십시오)

나머지는 다소 의견이 있지만 경험을 바탕으로합니다

  1. 테이블 이름에 관해서
    1. 단일 엔티티 이름으로 이동해야합니다 (문서 작성이 쉬워집니다).
    2. 여기서 Pascal Case를 사용해야합니다
  2. 필드 이름에 관해서
    1. 필드 이름에 camelCase를 사용하십시오.
    2. 정의가 확실히 복수형으로 이해되지 않는 한 짧은 단수 이름을 사용하십시오 (거의 결코 그렇지 않습니다)
  3. 자신의 함수 또는 저장 프로 시저 이름에 관해서
    1. 밑줄 _ 분리 사용
    2. 매개 변수화에 필드 이름 사용
  4. 내장 데이터베이스 기능 또는 언어 이름 (예 : SELECT)
    1. 특정 방식으로 대문자를 사용해야하는 경우가 아니라면 모든 대문자를 사용하십시오.
    2. 합리적이거나 필요한 것이 무엇인지 알기 위해 해당 언어의 API를 알아야합니다.
  5. 간격에 관해서
    1. 많은 사람들이 키워드에 대해 열 정렬을 사용하고 키워드가 아닌 것들에 대해서는 들여 쓰기를 사용합니다
    2. 많은 사람들이 필드가 각 줄에서 분리 될 때 행 시작 부분에 쉼표를 사용합니다 (선택 목록에서 특정 필드를 주석 처리하는 것이 더 쉬워집니다)
    3. 반환 값 헤더조차도 사물 이름의 일부로 공백을 사용하지 마십시오.
  6. 구두점에 관해서
    1. 괄호-사용하십시오. 그들은 무료입니다. 약속합니다.
    2. 세미콜론-사용하십시오. 그들은 당신을 망치지 않을 것입니다. 그들은 당신이 당신의 코드를 생각하도록 강요합니다. 그리고 그들은 위생이 좋습니다.
    3. 캐리지 리턴-다시 한 번 무료입니다. ;-) 코드를 읽을 수있게 만듭니다.

또한 일반적인 스타일 가이드를 적용하는 동안 Postgres 커뮤니티는 일반적으로 camelCase 또는 PascalCase를 사용하지 않고 대신 underscore_separation을 사용한다는 점을 인식해야합니다. 정말 중요한 비트 는 것을 보장하는 것입니다 수립하고 일관되게 모든 곳에서 특정 스타일을 사용 .


3
+1 "정말 중요한 것은 일관성을 유지하기 위해 어디에서나 특정 스타일을 설정하고 사용하는 것입니다." 일관성이 핵심입니다. 그것 없이는 생각할 필요가없는 것들에 대해 생각해야합니다.
Max Vernon

4
글쎄, PostgreSQL의 camelCase와 PascalCase는 약간 고통 스럽습니다. 당신이 정말로 그런 이름을 원한다면 이것을 인용 해야합니다. 그렇지 않으면 시스템은 자동으로 소문자로 만듭니다 (나는 거의 모든 대문자를 썼다.
dezso

데이터베이스 이름은 어떻습니까? 내가 사용해야 database_name, database-name, DatabaseName, databaseName, 등?
ma11hew28

1
이 답변이 실제로 PostgreSQL에 대한 것입니까? PG 특정 답변에서 테이블 이름에 PascalCase를 사용하라는 조언을 제공하는 경우 (a) 대부분의 예제가 소문자 키워드를 사용한다는 사실을 처리하는 방법 및 (b) 테이블 이름을 인용할지 또는 허용 할지를 언급해야한다고 생각합니다. PG는 소문자로 접습니다.
AndreKR

@AndreKR는 다음과 같습니다. 소프트웨어 개발자가 성인이되고 설명서를 읽는 방법을 알고 팀과 일관되게 코드를 작성하는 방법에 대해 논의하기를 기대합니다. 이 답변은 커뮤니티 위키이며 누구나 편집하고 개선 할 수 있습니다. 정확히 "이것은 유일한 방법"이라고 말할 수 없으며 일부 사람들이 소문자로 예제를 제공한다고해서 이것이 인생에서 유일한 방법이라는 의미는 아닙니다. 당신은 당신 자신의 길을 찾아야합니다. 이것이이 답변의 정신이었습니다. 커뮤니티 답변을 수정하여 개선하십시오. 감사!
jcolebrand

4

빠른 Google은 모범 사례를 나타내는 많은 사이트를 공개합니다. 하지 - 난 단지 두 가지 말을 (; 같은 영숫자가 아닌 문자에 간다 이식은 다른 탈출 메커니즘으로 인해 불가능하게된다) 공간 "내 테이블 이름"을 사용합니다. 이러한 종류의 메커니즘을 사용하면 일반적으로 대소 문자도 존중해야합니다. 영어 (또는 자신의) 언어로 충분한 글자와 단어가 있으며 식별자 길이가 충분합니다 (identifier_length <32, PostgreSQL이 64 인 시스템은 모르겠습니다). 그리고 동일한 작업을 수행하는 SQL 키워드 (RDBMS에 따라 다름)를 사용하지 마십시오.

같은 통계

SELECT "Field" FROM "Table";

유효 할 수 있습니다! 절대적으로 중요한 것은 명확하고 상대적으로 간단한 관습을 가지고 그것을 지키는 것입니다. 사람들은 당신이 알게 될 다른 의견을 가지고 있습니다-주제를 읽고 당신에게 "느낌"을 선택하십시오. 이 사이트 1 , 2 , 3 , 4 , 5 , ...를 참조하십시오 (더 많은 것이 있습니다).


고마워, 나는 내 자신의 검색에서 많은 사람들을 우연히 발견했습니다. 공식적인 스타일 가이드가 있는지 알고 싶었습니다.
Adam Matan

(singular_table_name / plural_table_name) 토론의 양쪽에는 내가 존중하는 다른 영역에 대한 의견이 많은 실무자가 있습니다. 나는 "단일"사람입니다-만약 당신이 원자력 발전소를 운영하고 있다면, 당신은 전혀 기록을보고 싶지 않은 catastrophic_meltdown이라는 테이블을 가지고있을 것입니다! 기본 키에 접미사 _id를 부여하고 자식 테이블에서 Parent_Table_Name_FK로 참조하십시오. 이것이 바로 제가하는 일입니다. 그 후에는 쉬워요! caps / no-caps와 관련하여 내 SQL 스크립트는 낙타 사례 (인용되지 않은)이며 내 진술은 가능하거나 그렇지 않을 수 있습니다.
Vérace
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.