답변:
OK, 먼저 테이블 이름 앞에 tbl을 두지 마십시오. 그것은 테이블입니다. 우리는 이미 그 일을했습니다. 이것을 헝가리 표기법 (Hungarian Notation)이라고하며 사람들은 5 년 이상 전에 그 일을 중단했습니다.
객체가 무엇인지에 따라 객체를 호출하십시오. 테이블에 직원 데이터가 있으면 "직원"이라고합니다. 컴퓨터에 대한 정보가 있으면 "컴퓨터"라고합니다. 컴퓨터를 직원에게 매핑하는 경우 "EmployeeComputer"또는 "ComputerEmployee"라고합니다 (개인적으로 "EmployeeComputer"가 더 좋습니다).
헝가리어 표기법을 사용하지 않는 것 외에는 사용할 올바른 명명 규칙이 없습니다. 객체 이름이 중요하다는 것을 이해하는 한.
orders되지 않으며 order사용자가 될 때마다 테이블 이름을 인용하지 않아도됩니다. 이는 group다른 키워드 에도 적용됩니다 . 다행히도 공통 키워드와 충돌하는 키워드는 거의 없습니다.
권한과 그룹화 모두에 스키마를 사용합니다 (SQL에서 네임 스페이스로 생각할 수도 있음). "tbl"등 대신에
코드가 데이터 스키마에 들어 가지 않습니다. 데이터 스키마 외부에 테이블이 없습니다. 원하는 경우 조회 또는 스테이징 스키마를 갖도록 확장 할 수도 있습니다.
우리가 사용하는 뷰는 vwSQL Server 2000의 테이블과 구별하기위한 것이 었으며 지금은 다소 레거시입니다.
개인적으로 저는 Fanö Bedingung 의 열렬한 팬입니다. 여기서 이름은 다른 유효한 이름의 시작이 될 수 없습니다.
둘째, 두 이름 사이의 해밍 거리는 하나 이상의 다른 문자보다 낫습니다.
예, 그것은 사전 디지털 시대의 규칙이지만 인생을 더 쉽게 만듭니다.
그리고 세 번째 이름은 발음 할 수 있어야합니다. 그렇지 않으면 음성 인식이 실현 될 때 화를 낼 것입니다.
나는 개인적 선호와 개발의 용이성으로 귀결되기 때문에 실제로 "최상의"명명 규칙이 있다는 것을 모른다. 내 충고는 명명 규칙을 선택하고 준수하는 것입니다. 밑줄로 단어를 구분하려면 모든 데이터베이스 개체에서 단어를 구분하십시오. camelCase를 사용하려면 모든 데이터베이스 오브젝트에서 사용하십시오.
우리 가게에서는 다음 규칙을 준수합니다.
우리는 단어를 밑줄로 분리하고 모든 소문자를 사용합니다.
테이블 이름은 dbo.person, dbo.invoice입니다.
다 대다 테이블 이름도 그 의미를 설명합니다 ( dbo.person_mm_address로 다 대다 관계가 매핑됨을 나타 내기 위해 mm 을 추가 함). 사용자 정의 저장 프로시 저는 객체와 수행중인 작업을 모두 설명합니다 : usp_person_select , usp_address_select_by_city 뷰와 함수는 저장 프로 시저와 동일한 규칙을 따릅니다 인덱스에는 테이블, 키 열 (순서대로) 및 클러스터 / 비 클러스터 표시가 포함됩니다. ix_person_last_name_first_name_nc
이것이 우리 가게에서 사용하는 것이므로 이러한 규칙이 귀하에게 적합하다는 것을 의미하지는 않습니다. 귀하와 귀하의 개발 팀이 유용하고 개발하기 쉽다고 동의 한 것을 선택하고, 귀하가 결정한 명명 규칙을 알고 사용하는 문화를 확립하십시오. 이 경우 데이터베이스에 생성 된 모든 객체에 대한 코드 검토가 포함됩니다. 시간이 지남에 따라 문서화 된 명명 규칙과 피어 코드 검토의 조합으로 인해 규칙과의 편차가 줄어 듭니다.
이 "답이없는"것이 어떤 식 으로든 도움이되기를 바랍니다.
나는 몇 년 전부터 이것에 만족하고 있습니다.
저렴한 공유 호스팅 패키지가있는 경우 데이터베이스 관리자 사이트, da_users, da_questions와 같은 모든 객체 앞에 프로젝트 약어를 사용해야합니다.
product_groupv하지 product_group_v뷰 (당신은보기와 테이블이 disticntion 주장하는 경우)?