데이터베이스 명명 규칙 - 접두어

Question

이 문제를 해결하는 데 많은 질문이 있다는 것을 알고 있습니다. 거기에는 많은 훌륭한 명명 규칙 제안이 있지만 우리 팀에서는 논쟁이있었습니다. sProducts 과 같은 기본 키 :

팀 구성원은 우리가 우리 테이블의 같은 이름을 지정해야한다고 주장의 정적과 시간을 의미하므로

자신의 시스템 (S, H) 두 prefixe의의를 있습니다 ProductGuid - 정말 미안해. 거기에는 전혀 논리가 없습니다. 그는 모든 커다란 오라클과 ibm 시스템이 그렇게 작동한다고 말합니다. 나는 oracle이나 ibm 시스템으로 일한 적이 없기 때문에 s와 h와 같은 접두어를 추가하는 관습이 있습니까? 그리고 그들은 무엇을지지합니까?

누가 거기에 있습니까, 누가 똑같습니까? 나는 그 질문에 대해 유감스럽게 생각합니다. 그러나 항상 s를 추가하고 단서가없는 이유를 모르겠습니다.

Answer 1

그는 모든 큰 오라클 및 ibm 시스템이 그렇게 작동한다고 말합니다.

꽤 큰 대명사입니다. 확률은 그가 틀렸어. 비록 내가 데이터베이스에 대해 몰랐다고해도 나는 말할 수있다. (저는 800 개 이상의 회사에서 컨설턴트를 해왔습니다.)

오늘의 신념을 테이블 이름으로 인코딩하면 내일에는 문제가 발생합니다. 테이블이 뷰가되고, 뷰가 테이블이되고, 뷰가 테이블 반환 함수가되고, 정적 테이블이 내일, "h- 워드"가되는 것은 드문 일이 아닙니다.

정적 테이블이 마침내 h-word가 될 때 테이블을 어떻게 처리합니까? 이름 만 남겨주세요? 이제는 그 테이블을 찾을 때마다 더 열심히 생각해야합니다. 이름을 h- 단어로 변경 하시겠습니까? 이제 정적에 의존하는 모든 앱을 해독했습니다. 이름을 변경하고 이전 이름으로 업데이트 할 수있는보기를 만드시겠습니까? 처음에는 좋은 이름으로 피할 수있는 많은 작업처럼 보입니다.

Answer 2

질문에 대한 답변으로 혼란 스럽습니다. 당신은 "접미사"를 언급하지만 아직 "접두사"를 보여줍니다.

많은 종교 문제는 여기에 있습니다 ...

나는 필드/열/속성의 맥락에서이 문제를 제시한다. 다른 종류의 사물들도 일관된 형식을 가질 필요가 있습니다.

많은 명명 규칙의 근원은 명명 표준과 동일하지 않지만, 1970 년대의 IBM의 "OF Language"입니다.

OF는 PRIME-MODIFIER-CLASS 형식을 사용하여 고객 계정 번호에 대해 CUST-ACCT-NO를 생성했습니다.

좋은 이름은 여러 가지 작업을 수행하기를 원합니다. 어떤 데이터 종류 (예 : 날짜 또는 텍스트)와 비즈니스에 대한 것인지 나타냅니다.

CLASS 단어 (접미사이지만 헝가리 표기법의 접두사)는 오늘날 데이터 형식과 같은 것이 될 수있는 짧은 목록입니다. 날짜, 텍스트, 코드, 플래그 (이진 오늘), 금액, & 등등.

CLASS 단어는 12 개 또는 2 개 이하 여야합니다.

PRIME/MODIFIER 단어는 시스템에서 지원하는 비즈니스 문제에 더 중점을 둡니다.

어쨌든 ... 가장 어려운 부분은 일관성을 유지하는 것입니다.

CODE를 CD 및 CDE로 약어로 표기하십시오.

대시 (-), 밑줄 (_), camelCase와 같은 구분 기호 문제는 기술적 인 환경 &에 의해 설명 될 수 없습니다.

가장 중요한 문제는 일관성있는 것입니다. 인간이 끔찍한 것입니다.

올바른 명명 규칙이 없습니다. 당신이 꿈꾸는 것이 다른 사람들이 술에 취하기에는 너무 복잡하다면 나쁜 선택을 한 것입니다.

BTW ... 명명 규칙은 우리가 주로 다루는 것입니다 ... 안개가 자욱한 아이디어입니다. 운이 좋으면 먼지가 많고 잊혀진 매뉴얼에 적혀 있습니다.

명명 표준은 컴파일러와 동일하게 자동 적용되는 항목입니다.

저는 (DBA에 의해 시행 된) 뛰어난 명명 규칙을 가진 대형 시스템에서 작업했습니다 ... 데이터 요소 또는 단락 이름 &을 가장 잘 볼 수 있다는 느낌은 가장 해방 된 것을 알고 있습니다.