테이블 이름 지정 : 밑줄 대 Camelcase? 네임 스페이스? 단수 대 복수?

89

저는 StackOverflow에 대한 몇 가지 질문 / 답변을 읽고 데이터베이스에서 테이블 이름을 지정하기 위해 '최고'를 찾으려고하거나 반드시 받아 들여야한다고 말해야합니다.

대부분의 개발자는 데이터베이스 (JAVA, .NET, PHP 등)가 필요한 언어에 따라 테이블 이름을 지정하는 경향이 있습니다. 그러나 나는 이것이 옳지 않다고 느낍니다.

지금까지 테이블 이름을 지정하는 방식은 다음과 같습니다.

doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents

내가 염려하는 것은 다음과 같습니다.

읽기 쉬움
테이블이있는 모듈의 빠른 식별 (의사 || 환자)
이해하기 쉽고 혼란을 방지합니다.

명명 규칙에 대한 의견을 읽고 싶습니다. 감사합니다.

database database-design

— MarioRicalde
소스

180

일관성을 유지하는 것이 사용하는 특정 체계보다 훨씬 더 중요합니다.

— 데이비드 오닐
소스

21

다시 말해, 예, 잘하셨습니다. 몇 가지 일관된 계획을 확인했습니다. 그것으로 타!

— Phil H

3

댓글에 +1. 또한 현재 이름 지정 체계에 대한 부수적으로 PascalCase가 더 좋습니다. 특히 SQL 쿼리에 별칭을 사용하지 않는 경우 더욱 그렇습니다. 이렇게하면 테이블 열 이름에 camelcase를 사용하고 테이블 이름에 Pascal Case를 사용할 수 있습니다.

— MarioRicalde 2009

3

테이블 이름에 대한 Pascal / camel 케이스로 인해 몇 가지 문제가 발생할 수 있습니다. 모든 테이블에는 파일 시스템에 파일이 있으며 일부는 대소 문자를 구분하지 않습니다 (예 : OSX).

— ismriv

2

@ismriv 그것은 일관성이없는 경우에만 문제 입니다. 동일한 일관된 대소 문자를 가진 테이블 / 뷰 / 열을 항상 참조하는 경우 문제가 없어야합니다. 이러한 이름을 쓸 때 게으르지 않으면 큰 도움이됩니다. 나중에 읽을 때 유리합니다. 테이블에 PascalCase를 사용하고 열에 camelCase를 사용하면 이름 유형을 한 눈에 식별하는 데 도움이되며 일반적인 객체 지향 규칙을 모방합니다.

— TWiStErRob

난 완전히 그 일관성이 중요합니다 동의하지만, 이것은 오래된 질문이고 Redshift에와 눈송이 같은 새로운 데이터베이스 플랫폼을 사용하는 사람들에 대한 모든 대문자 또는 소문자 중 식별자의 기본은, 나는 것을 추가 거라고 이다 에 대해 생각하는 것은 매우 중요합니다 당신의 이름 지정 규칙은 처음부터 시작됩니다. 이러한 플랫폼에서 Camel Case와 같은 명명 규칙을 사용하도록 선택하면 나중에 불필요한 골치 거리가 발생할 수 있습니다. 예를 들어 항상 인용 식별자를 사용해야하며 개체 이름 확인은 예기치 않은 결과를 생성 할 수 있습니다.

— Nathan Griffiths

22

나는 일반적으로 PascalCase를 사용하고 엔티티는 단수입니다.

DoctorMain
DoctorProfile
DoctorPatient

내 응용 프로그램의 클래스 이름 지정 규칙을 모방하여 모든 사람이 모든 것을 매우 깔끔하고, 깨끗하고, 일관되고 , 이해하기 쉽게 유지 합니다.

— 저스틴 니스 너
소스

3

네 ... 네. 오늘 아침에 약간 안개가 낀다. 편집하는 중 ... 감사합니다.

— Justin Niessner 2009

3

"CapitalCase"라고도합니다.

— corsiKa 2013

3

30 년 동안 "CapitalCase"라는 이름을 들어 본 적이 없습니다. 가장 많이 '낙타 케이스'라고 들었는데 최근에는 '파스칼 케이스'가 채택됐다. 나는 역사적으로 대부분 대소 문자를 구분하지 않았을 때 사람들이 SQL에 camel case를 사용하는 것처럼 보이는 이유를 알아보기 위해 여기에 왔습니다. 나는 확실히 시대에 뒤처지고 싶지 않습니다.

— Sinthia V

@SinthiaV 나는 다른 사람에 대해 잘 모르지만 우리의 경우 JS ORM을 사용하고 있기 때문에 (안타깝게도) 옵션은 1) db에서 camelCase를 사용하여 규칙을 중단합니다. 2) JS에서 snake_case를 사용하여 규칙을 중단합니다. 3) camelCase를 매핑합니다. JS에서 db의 snake_case로. 우리는 db에서 camelCase를 사용하기로 초기 생각없이 결정했고 그렇게 나쁘지는 않았지만 모든 것을 인용하는 것이 약간 번거 롭습니다.

— Andy

@SinthiaV는 쓸모없는 주석으로 실제 SO 질문과 관련하여 PascalCase는 camelCase와 동일하지 않습니다. PascalCase는 각 단어의 첫 글자를 대문자로 표시하는 반면 (중요하게 첫 번째 포함) camelCase는 첫 번째 단어 뒤의 단어 만 대문자로 표시합니다. 또한 읽기 : medium.com/better-programming/...

— curiouser

11

SQL의 대소 문자를 구분하지 않는 특성은 Underscores_Scheme. 그러나 최신 소프트웨어는 모든 종류의 명명 체계를 지원합니다. 그러나 때때로 성가신 버그, 오류 또는 인간의 요인으로 이어질 수 UPPERCASINGEVERYTHING있도록 모두 선택하는 사람들, 그 Pascal_Case와 Underscore_Case좋은 장소에 모든 신경 라이브 체계를.

— terR0Q
소스

10

위의 대부분의 집계 :

데이터베이스의 케이스에 의존하지 마십시오.
이름의 대소 문자 구분 부분을 고려하지 말고 단어 만
귀하의 언어에 대한 표준 구분 기호 또는 대소 문자를 사용하십시오.

그러면 환경간에 이름을 쉽게 번역 (자동으로도) 할 수 있습니다.

하지만 또 다른 고려 사항을 추가하겠습니다. 앱의 클래스에서 데이터베이스의 테이블로 이동할 때 다른 요소가 있음을 알 수 있습니다. 데이터베이스 개체에는 뷰, 트리거, 저장된 프로 시저, 인덱스, 제약 조건 등이 있습니다. 이름도 필요합니다. 예를 들어, 일반적으로 단순한 "select * from foo"인 뷰를 통해서만 테이블에 액세스 할 수 있습니다. 접미사 '_v'만있는 테이블 이름으로 식별되거나 다른 스키마에 넣을 수 있습니다. 이러한 단순한 추상화 계층의 목적은 한 환경에서 변경을 허용하여 다른 환경에 영향을주지 않도록 필요한 경우 확장 할 수 있다는 것입니다. 이것은 위의 이름 지정 제안을 깨뜨리지 않습니다. 몇 가지만 설명하면됩니다.

— KenFar
소스

8

나는 밑줄을 사용합니다. 몇 년 전에 Oracle 프로젝트를 수행했는데 Oracle이 내 모든 개체 이름을 대문자로 강제 설정 한 것처럼 보였습니다. 나는 정말로 오라클 사람이 아니기 때문에 내가 알지 못했던 방법이 있었을지도 모르지만 밑줄을 사용하게되었고 다시는 돌아 오지 않았습니다.

— 레이
소스

2

11g 이상에서는 테이블 이름을 큰 따옴표로 묶으면 대소 문자가 유지되는 것 같습니다. 나중에 참조 할 수 있도록 여기에 넣습니다. Postgres도 그렇게하는 것이 확실하지만 다른 DB 엔진은 그렇지 않을 수 있습니다.

— John O

8

질문은 특정 플랫폼이나 DB 엔진에 국한되지 않기 때문에 최대한의 이식성을 위해 항상 소문자 테이블 이름을 사용해야합니다.

/ [a-z _] [a-z0-9 _] * /는 실제로 서로 다른 플랫폼간에 원활하게 번역되는 유일한 이름 패턴입니다. 소문자 영숫자 + 밑줄은 항상 일관되게 작동합니다.

다른 곳에서 언급했듯이 관계 (테이블) 이름은 단수 여야합니다. http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html

— 리치 레머
소스

나는 동의합니다-밑줄은 Pascal 또는 camel Casing과 비교할 때 최소한의 문제가 있습니다. 특히 이름이 모델, dto 및 프런트 엔드로 이동할 때 끝납니다.

— Saulius

6

나는 그것이 당신이 사용하는 언어의 관례에 달려 있다고 말하는 사람들의 의견에 동의하는 경향이 있습니다 (예 : C #의 경우 PascalCase, Ruby의 경우 snake_case).

하지만 camelCase는 절대로하지 마십시오.

— 마크 렌들
소스

2

에이다 : Pascal_Case_With_Underscores

— uetoyo

6

이름 지정 규칙이 다른 두 개의 다른 언어로 동일한 테이블에 액세스하려는 경우 이는 의미가 없습니다.

— Daniel W.

5

다른 많은 의견을 읽은 후 언어의 명명 규칙을 사용하는 것이 매우 중요하다고 생각합니다. 응용 프로그램의 유일한 개발자 인 경우에만 명명 규칙보다 일관성이 더 중요합니다. 가독성을 원한다면 (매우 중요한) 각 언어에 대한 명명 규칙을 사용하는 것이 좋습니다. 예를 들어 MySQL에서는 모든 플랫폼이 대소 문자를 구분하지 않으므로 CamelCase를 사용하지 않는 것이 좋습니다. 그래서 여기 밑줄이 더 좋아집니다.

— 블라드 마누엘 무레 샨
소스

1

절대적으로 동의합니다 !!! 특히 MySQL의 당신은에서가 윈도우 모두에서 실행하는 경우 camelCase에 camelcase. 그래서 뱀 케이스를 갖는 것이 훨씬 좋습니다. 또한 Modern software however supports any kind of naming scheme당신 에 대해 yop이 마지막 버전 소프트에 대한 코드를 작성할 것이라는 보장이 없습니다. 특히 데이터베이스의 경우 회귀 비용을 생각할 때 버전 업데이트가 사소하지 않습니다.

— Cherry

2

이건 내 5 센트입니다. 하나의 프로젝트에 다른 공급 업체의 DB를 사용하는 경우 두 가지 가장 좋은 방법이 있다는 결론에 도달했습니다.

밑줄을 사용하십시오.
따옴표와 함께 카멜 케이스를 사용하십시오.

그 이유는 일부 데이터베이스는 모든 문자를 대문자로, 일부는 소문자로 변환하기 때문입니다. 그래서, 당신이있는 경우 myTable가 될 것이다 MYTABLE또는 mytable당신은 DB와 함께 작동 할 때.

— Pavel_K
소스

1

안타깝게도이 질문에 대한 "최상의"답변은 없습니다. @David가 말했듯이 일관성은 명명 규칙보다 훨씬 중요합니다.

— 케인
소스

1

단어를 분리하는 방법은 다양하므로 더 좋아하는 것을 선택해야합니다. 그러나 동시에 테이블 이름이 단수 여야한다는 의견이 거의 일치하는 것 같습니다.

— 하비에르
소스

1

명명 규칙은 언어 범위 내에 존재하며 언어마다 명명 규칙이 다릅니다.

SQL은 기본적으로 대소 문자를 구분하지 않습니다. 따라서 snake_case는 널리 사용되는 규칙입니다. SQL은 구분 식별자도 지원합니다. 따라서 camelCase (Java, where fields == columns) 또는 PascalCase (C #, where tables == classes and columns == fields)와 같은 옵션에서 대소 문자를 혼합합니다. DB 엔진이 SQL 표준을 지원할 수 없다면 그게 문제입니다. 그것과 함께 살거나 다른 엔진을 선택할 수 있습니다. (그리고 C #이 달라야 만하는 이유는 두 가지 모두를 코딩하는 사람들에게 더 심각한 문제입니다.)

서비스와 애플리케이션에서 하나의 언어 만 사용하려는 경우 모든 계층에서 해당 언어의 규칙을 사용하십시오. 그렇지 않으면 해당 언어가 사용되는 도메인에서 가장 널리 사용되는 언어 규칙을 사용하십시오.

— 크리스 골 리지
소스