테이블 이름 지정 : 밑줄 대 Camelcase? 네임 스페이스? 단수 대 복수?
나는 StackOverflow에 대한 몇 가지 질문 / 답변을 읽고 데이터베이스에서 테이블 이름을 지정하기 위해 '최고'를 찾으려고하거나 반드시 받아 들여야한다고 말해야합니다.
대부분의 개발자는 데이터베이스 (JAVA, .NET, PHP 등)가 필요한 언어에 따라 테이블 이름을 지정하는 경향이 있습니다. 그러나 나는 이것이 옳지 않다고 느낍니다.
지금까지 테이블 이름을 지정하는 방식은 다음과 같습니다.
doctorsMain
doctorsProfiles
doctorsPatients
patientsMain
patientsProfiles
patientsAntecedents
내가 염려하는 것은 다음과 같습니다.
- 읽기 쉬움
- 테이블이있는 모듈의 빠른 식별 (의사 || 환자)
- 이해하기 쉽고 혼란을 방지합니다.
명명 규칙에 대한 의견을 읽고 싶습니다. 감사합니다.
일관성을 유지하는 것이 사용하는 특정 체계보다 훨씬 더 중요합니다.
저는 일반적으로 PascalCase를 사용하며 엔티티는 단수입니다.
DoctorMain
DoctorProfile
DoctorPatient
내 응용 프로그램의 클래스 이름 지정 규칙을 모방하여 모든 사람이 모든 것을 매우 깔끔하고, 깨끗하고, 일관되고 , 이해하기 쉽게 유지 합니다.
SQL의 대소 문자를 구분하지 않는 특성은 Underscores_Scheme. 그러나 최신 소프트웨어는 모든 종류의 명명 체계를 지원합니다. 그러나 때때로 성가신 버그, 오류 또는 인간의 요인으로 이어질 수 UPPERCASINGEVERYTHING있도록 모두 선택하는 사람들, 그 Pascal_Case와 Underscore_Case좋은 장소에 모든 신경 라이브 체계를.
나는 밑줄을 사용합니다. 몇 년 전에 Oracle 프로젝트를 수행했는데 Oracle이 모든 개체 이름을 대문자로 강제 설정 한 것 같았습니다. 나는 정말로 오라클 사람이 아니기 때문에 내가 알지 못했던 방법이 있었을 수도 있지만, 밑줄을 사용하게되었고 다시는 돌아 오지 않았습니다.
위의 대부분의 집계 :
- 데이터베이스의 케이스에 의존하지 마십시오.
- 이름의 대소 문자 구분 부분을 고려하지 말고 단어 만
- 귀하의 언어에 대한 표준 구분 기호 또는 대소 문자를 사용하십시오.
그러면 환경간에 이름을 쉽게 번역 (자동으로도) 할 수 있습니다.
하지만 또 다른 고려 사항을 추가하겠습니다. 앱의 클래스에서 데이터베이스의 테이블로 이동할 때 다른 요소가 있음을 알 수 있습니다. 데이터베이스 개체에는 뷰, 트리거, 저장된 프로 시저, 인덱스, 제약 조건 등이 있습니다. 이름도 필요합니다. 예를 들어, 일반적으로 단순한 "select * from foo"인 뷰를 통해서만 테이블에 액세스 할 수 있습니다. 접미사 '_v'만있는 테이블 이름으로 식별되거나 다른 스키마에 넣을 수 있습니다. 이러한 단순한 추상화 계층의 목적은 한 환경에서 변경을 허용하여 다른 환경에 영향을주지 않도록 필요한 경우 확장 할 수 있다는 것입니다. 이것은 위의 이름 지정 제안을 깨뜨리지 않습니다. 몇 가지만 설명하면됩니다.
나는 그것이 당신이 사용하는 언어의 관습에 달려 있다고 말하는 사람들의 의견에 동의하는 경향이 있습니다 (예 : C #의 경우 PascalCase, Ruby의 경우 snake_case).
하지만 camelCase는 절대로하지 마십시오.
질문은 특정 플랫폼이나 DB 엔진에 국한되지 않기 때문에 최대한의 이식성을 위해 항상 소문자 테이블 이름을 사용해야합니다.
/ [a-z _] [a-z0-9 _] * /는 실제로 서로 다른 플랫폼간에 원활하게 변환되는 유일한 이름 패턴입니다. 소문자 영숫자 + 밑줄은 항상 일관되게 작동합니다.
다른 곳에서 언급했듯이 관계 (테이블) 이름은 단수 여야합니다. http://www.teamten.com/lawrence/programming/use-singular-nouns-for-database-table-names.html
다른 많은 의견을 읽은 후에는 언어의 명명 규칙을 사용하는 것이 매우 중요하다고 생각합니다. 응용 프로그램의 유일한 개발자 인 경우에만 명명 규칙보다 일관성이 더 중요합니다. 가독성을 원한다면 (매우 중요한) 각 언어에 대한 명명 규칙을 사용하는 것이 좋습니다. 예를 들어 MySQL에서는 모든 플랫폼이 대소 문자를 구분하지 않기 때문에 CamelCase를 사용하지 않는 것이 좋습니다. 그래서 여기 밑줄이 더 좋습니다.
이건 내 5 센트입니다. 하나의 프로젝트에 다른 공급 업체의 DB를 사용하는 경우 두 가지 가장 좋은 방법이 있다는 결론에 도달했습니다.
- 밑줄을 사용하십시오.
- 따옴표와 함께 카멜 케이스를 사용하십시오.
그 이유는 일부 데이터베이스는 모든 문자를 대문자로, 일부는 소문자로 변환하기 때문입니다. 그래서, 당신이있는 경우 myTable가 될 것이다 MYTABLE또는 mytable당신은 DB와 함께 작동 할 때.
불행히도이 질문에 대한 "최상의"답변은 없습니다. @David가 말했듯이 일관성은 명명 규칙보다 훨씬 더 중요합니다.
단어를 분리하는 방법은 다양하므로 더 좋아하는 것을 선택해야합니다. 그러나 동시에 테이블 이름이 단수 여야한다는 의견이 거의 일치하는 것 같습니다.
명명 규칙은 언어 범위 내에 존재하며 다른 언어에는 다른 명명 규칙이 있습니다.
SQL is case-insensitive by default; so, snake_case is a widely used convention. SQL also supports delimited identifiers; so, mixed case in an option, like camelCase (Java, where fields == columns) or PascalCase (C#, where tables == classes and columns == fields). If your DB engine can't support the SQL standard, that's its problem. You can decide to live with that or choose another engine. (And why C# just had to be different is a point of aggravation for those of us who code in both.)
If you intend to ever only use one language in your services and applications, use the conventions of that language at all layers. Else, use the most widely used conventions of the language in the domain where that language is used.
'Development Tip' 카테고리의 다른 글
| CSS에서 maxlength를 지정할 수 있습니까? (0) | 2020.10.15 |
|---|---|
| CSS : 하나의 요소를 가리키면 여러 요소에 효과가 있습니까? (0) | 2020.10.15 |
| Intent.FLAG_ACTIVITY_CLEAR_TOP를 사용하여 활동 스택을 지우는 방법은 무엇입니까? (0) | 2020.10.15 |
| PSR-0은 무엇을 의미합니까? (0) | 2020.10.14 |
| NSString stringWithFormat에서 인수 위치 / 인덱스를 지정하는 방법이 있습니까? (0) | 2020.10.14 |