MySQL에 대한 명명 규칙이 있습니까?


163

내가하는 방법은 다음과 같습니다.

  1. 표 이름 (예를 들어, 단수의 소문자, 개별 단어 사용의 밑줄이고,이다 foo, foo_bar
  2. 나는 일반적으로 (항상 그런 것은 아니지만) 자동 증분 PK를 가지고 있습니다. : 나는 다음과 같은 규칙을 사용 tablename_id(예를 들어 foo_id, foo_bar_id등).
  3. 테이블에 외래 키 인 열이 포함되어 있으면 테이블의 출처가 무엇이든 해당 키의 열 이름을 복사합니다. 예를 들어 테이블 foo_bar에 FK가 있습니다 foo_id(여기서 foo_idPK는 foo).
  4. 참조 무결성을 강화하기 위해 FK를 정의 할 때 다음을 사용합니다 tablename_fk_columnname(예 : 추가 예 3 foo_bar_foo_id). 이것은 테이블 이름 / 열 이름 조합이므로 데이터베이스 내에서 고유해야합니다.
  5. PK, FK, 나머지 열을 알파벳순으로 정렬합니다.

더 나은 표준 방법이 있습니까?


6
자동 증분 PK 만 "id"로 사용하는 것이 잘못 되었습니까? 왜? 열 이름은 테이블 컨텍스트에서만 의미가 있습니다. 따라서 모든 테이블에 하나의 "id"가 있으며 FK에 대해 많은 id_ <table_name>이있을 수 있습니다.
Zbyszek

3
@ Zbyszek 그에 대한 가장 간단한 이유는 단순히 일관성 / 단순성 때문이라고 생각합니다. 오히려이없는 이상 id_tableB=> 오 전혀 다른 이름의 열을 id 의 일관성 id_tableB>이 = id_tableB단지 깔끔한 외모 ... 또는 영업 이익은 그것을처럼 : foo_id=> foo_id보다는 foo_id=>id
돈 치들

답변:


106

나는 가장 먼저 말하고 싶습니다 : 일관성이 있어야합니다.

나는 당신이 당신의 질문에 요약 한 규칙으로 거의 거기에 있다고 생각합니다. 그러나 몇 가지 의견 :

포인트 1과 2는 좋았습니다.

포인트 3-슬프게도 이것이 항상 가능한 것은 아닙니다. foo_bar열이 foo_id있고 테이블 열 another_foo_id을 참조 하는 단일 테이블에 어떻게 대처할 것인지 생각해보십시오 . 이것을 다루는 방법을 고려할 수도 있습니다. 이것은 약간의 코너 케이스입니다!foofoo_id

포인트 4-포인트 3과 유사합니다. 외래 키 이름 끝에 숫자를 도입하여 둘 이상의 참조 열을 가질 수 있습니다.

포인트 5-나는 이것을 피할 것입니다. 그것은 당신에게 거의 제공하지 않으며 나중에 테이블에서 열을 추가하거나 제거하려고 할 때 두통이 될 것입니다.

다른 요점은 다음과 같습니다.

인덱스 명명 규칙

인덱스 이름 지정 규칙을 도입 할 수도 있습니다. 이는 수행하려는 데이터베이스 메타 데이터 작업에 큰 도움이됩니다. 예를 들어 인덱스를 호출 foo_bar_idx1하거나 foo_idx1전적으로 자신에게 달려 있지만 고려할 가치가 있습니다.

단수 대 복수 열 이름

테이블 이름뿐만 아니라 열 이름에서 복수 대 단일의 가시적 인 문제를 해결하는 것이 좋습니다. 이 주제는 종종 DB 커뮤니티에서 큰 논쟁 을 일으 킵니다 . 테이블 이름과 열 모두에 대해 단일 형식을 고수합니다. 그곳에. 내가 말했어

여기서 가장 중요한 것은 물론 일관성입니다!


포인트 5보다 나은 점은 무엇입니까? 왜 두통이 될 수 있습니까?
Rasshu

7
후속 적으로, 나는이 verry가 나중에 올 사람들에게 도움이된다는 것을 알았습니다 : launchbylunch.com/posts/2014/Feb/16/sql-naming-conventions/…
Enissay

1
두 개의 이름 (DocumentChapter, DocumentVersion, DocumentType 등)으로 구성된 모델의 객체를 보유하는 테이블의 이름을 지정하기위한 "체계"를 찾는 데 어려움을 겪고 있습니다. 예를 들어 DocumentType i의 경우 이름을 documenttype또는로 지정할 수 document_type있습니다. 나는 후자를 선호하지만, 대부분의 경우 많은 관계를 가지고 있으며 다음과 같은 테이블이 필요합니다 document_document_type. 이것을 처리하는 방법에 대한 제안?
lexith

@ rsb2097 Re : point 5-끝에 하나의 열을 추가 한 후 주문이 유효하지 않을 수 있습니다. 불필요한 오버 헤드이므로 열 순서를 다시 지정해야하는 제약 조건을 추가해서는 안됩니다.
윌 셰퍼드

21

일관성은 모든 명명 표준의 핵심입니다. 논리적이고 일관성있는 한 99 %가 있습니다.

표준 자체는 개인 취향이 매우 뛰어나므로 표준이 마음에 들면 표준으로 실행하십시오.

귀하의 질문에 대답하기 위해-아니오, MySQL에는 선호하는 명명 규칙 / 표준이 없으므로 자신을 굴리는 것이 좋습니다 (그리고 논리적으로 보입니다).



4

고맙게도 PHP 개발자는 내가 알고있는 일부 개발 커뮤니티와 같이 "낙타 사건의 큰 부분"이 아닙니다.

컨벤션은 괜찮습니다.

그들이 a) 단순하고 b) 일관성있는 한 문제가 없습니다. :)

추신 : 개인적으로, 나는 5) 과잉이라고 생각합니다 ...


2
낙타 사건과는 달리, 낙타 사건은 실제로 많은 DB 커뮤니티에서 눈살을 찌푸리고 있습니다. 일부 RDBMS는 사례를 제거하거나 모든 것을 대문자로 바꾸는 지점에 대해 대소 문자를 구분하지 않기 때문에 실제로는 매우 빨리 추악합니다.
mal-wan

@ mwan : 어떤 RDBMS를 지정할 수 있습니까? 그리고 나는 낙타 사건 기수입니다. 대문자는 내 스키마에서 조인 테이블과 필드의 경우 단어 경계를 나타내는 하나의 목적으로 만 사용되므로 _는 othertable_id를 독점적으로 표시 할 수 있습니다 (예 : 테이블 이름 = othertable 및 해당 테이블의 필드 = id ). 또한 다른 RDBMS가 대소 문자를 구분하지 않는다면 실제로 중요한 것은 무엇입니까? 나는 같은 테이블의 대문자와 소문자 버전을 결코 가지지 않을 것입니다! 아, 그리고 대소 문자를 구분하지 RDBMS를 선호하지 않을 - 차라리 일관성있는 코드를 써서
사무엘 Fullman

7
CamelCase를 작성 MySQL은, : 나는 낙타 표기법과 우리가 사용하는 제품의 이름을 싫어 MySQL의 사용자의 아이러니 같은
DBX12

1
@ DBX12 pedantic하기 위해, 그것은 camelCase가 아니라 PascalCase이지만, 당신의 요점은 여전히 ​​유효합니다.
MarredCheese

@MarredCheese 그것에 대해 생각하지 않았지만 당신은 옳습니다. camelCase는 처음에 혹이 없어야합니다.
DBX12

1

간단한 답변 : NO

글쎄, 적어도 오라클이나 커뮤니티가 권장하는 명명 규칙은 아니지만 기본적으로 MySQL 설명서에 표시된 것과 같이 식별자에 대한 규칙과 제한을 숙지해야합니다 : https://dev.mysql.com /doc/refman/8.0/en/identifiers.html

당신이 따르는 명명 규칙에 관해서는, 그것은 괜찮습니다. 숫자 5는 약간 불필요합니다. 데이터베이스 관리를위한 대부분의 시각적 도구는 열 이름을 정렬하는 옵션을 제공한다고 생각합니다 (DBeaver를 사용하고 있습니다). purpouse가 테이블을 시각적으로 멋지게 표현하고 있다면이 옵션을 사용할 수 있습니다.

개인적인 경험으로, 나는 이것을 추천 할 것입니다 :

  • 소문자를 사용하십시오 . 이것은 데이터베이스를 한 서버에서 다른 서버로 마이그레이션 할 때 거의 상호 운용성을 보장합니다. 때로는 lower_case_table_names올바르게 구성되어 있지 않고 단순히 camelCase 또는 PascalCase 표준 (대소 문자 구분 문제)을 인식하지 못해 서버에서 오류가 발생하기 시작합니다.
  • 짧은 이름 . 간단하고 명확합니다. 가장 쉽고 빠른 것은 테이블이나 열을 더 잘 식별하는 것입니다. 짧은 시간에 많은 다른 쿼리를 만들 때 모든 것을 간단하게 작성하고 읽는 것이 좋습니다.
  • 접두사를 피하십시오 . 다른 응용 프로그램의 테이블에 동일한 데이터베이스를 사용하지 않는 한 접두사를 사용하지 마십시오. 이렇게하면 검색어에 더 자세한 정보 만 추가됩니다. 예를 들어 기본 키와 외래 키를 식별하려는 경우 일반적으로 테이블 이름이 id 열의 접두사로 사용되는 경우에 유용 할 수 있습니다.
  • 단어를 구분하려면 밑줄을 사용하십시오 . 당신은 여전히 밑줄을 사용하는 등 테이블, 열을 명명에 대해 두 개 이상의 단어를 사용하려면 separating_the_words ,이 (당신을 감사하고 당신의 눈과 스트레스를 뇌가 예정) 가독성을 위해 도움이됩니다.
  • 일관성을 유지하십시오 . 자신의 표준을 갖추었다면 따르십시오. 규칙을 만드는 사람이되지 말고 규칙을 어기는 사람은 부끄러운 일입니다.

"Plural vs Singular"이름은 어떻습니까? 자, 이것은 대부분 개인 취향의 상황입니다. 필자의 경우 테이블을 요소 컬렉션 또는 패키지 containsig 요소로 생각하기 때문에 복수 이름을 사용하려고 시도하므로 복수 이름이 의미가 있습니다. 열을 해당 테이블 요소에 대해 개별적으로 설명하는 속성으로 볼 수 있으므로 열의 단수 이름입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.