학계는 테이블 이름이 속성을 저장하는 엔티티의 단수 여야한다고합니다.
나는 이름 주위에 대괄호가 필요한 T-SQL을 싫어하지만 Users
테이블의 이름 을 단수로 바 꾸었습니다 .
내 직감은 단수를 유지하는 것이 더 정확하다는 것입니다. 그러나 내 직감은 괄호 안에 공백이있는 열 이름과 같은 바람직하지 않은 항목을 나타냅니다.
내가 머물러야합니까, 아니면 가야합니까?
답변
다른 사람들은 “표준”에 이르기까지 꽤 좋은 답변을 주었지만, 나는 이것을 추가하고 싶었습니다 … “사용자”(또는 “사용자”)가 실제로 테이블에 보관 된 데이터에 대한 완전한 설명이 아닐 수도 있습니다 ? 테이블 이름과 특이성에 너무 미쳐서는 안되지만 “Widget_Users”(여기서 “Widget”은 응용 프로그램 또는 웹 사이트의 이름)와 같은 것이 더 적절할 것입니다.
답변
나는 같은 질문을했고, 여기에있는 모든 답변을 읽은 후에는 분명히 SINGULAR에 머물러 있습니다.
이유 1 (개념). “AppleBag”와 같은 사과가 들어있는 주머니를 생각할 수 있습니다. 0, 1 개 또는 백만 개의 사과가 들어 있는지 여부는 중요하지 않으며 항상 같은 주머니입니다. 테이블은 컨테이너입니다. 테이블 이름은 테이블에 포함 된 데이터의 양이 아니라 포함 된 내용을 설명해야합니다. 또한, 복수 개념은 구어 언어에 관한 것입니다 (실제로 하나 이상이 있는지 여부를 결정하기 위해).
이유 2 . (편의). 복수 이름보다 단수 이름으로 나오는 것이 더 쉽습니다. 객체는 불규칙 복수형 또는 복수형이 아닐 수 있지만 항상 단수형을 갖습니다 (뉴스와 같은 예외는 거의 없음).
- 고객
- 주문
- 사용자
- 상태
- 뉴스
이유 3 . (미학과 질서). 특히 마스터-디테일 시나리오에서 이것은 더 잘 읽히고 이름별로 더 잘 정렬되며 더 논리적 인 순서를 갖습니다 (Master first, Detail second) :
- 1. 주문
- 2. 주문 세부 사항
다음과 비교 :
- 1. 주문 세부 사항
- 2. 주문
이유 4 (단순성). 테이블 이름, 기본 키, 관계, 엔터티 클래스를 모두 합하면 두 가지 (단수 클래스, 복수 테이블, 단수 필드, 단수 복수 마스터 세부 정보) 대신 하나의 이름 (단수) 만 인식하는 것이 좋습니다. .)
Customer
Customer.CustomerID
CustomerAddress
public Class Customer {...}
SELECT FROM Customer WHERE CustomerID = 100
“고객”을 처리하고 있다는 것을 알게되면 모든 데이터베이스 상호 작용 요구에 대해 동일한 단어를 사용하게됩니다.
이유 5 . (세계화). 세계가 점점 작아지고 있습니다. 모든 국적의 팀을 보유하고있을 수 있습니다. 비영어권 프로그래머가 “리포지토리”보다 “리포지토리”또는 “상태”대신 “상태”를 생각하는 것이 더 쉬울 것입니다. 단수 이름을 사용하면 오타로 인한 오류가 줄어들고 “어린이 또는 어린이입니까?”라고 생각할 필요가 없어 시간이 절약되므로 생산성이 향상됩니다.
이유 6 . (왜?) 쓰기 시간을 절약하고 디스크 공간을 절약하며 컴퓨터 키보드를 더 오래 사용할 수 있습니다!
SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 100
당신은 3 글자, 3 바이트, 3 여분의 키보드 적중을 저장했습니다 🙂
마지막으로 예약 된 이름으로 엉망이되는 이름을 지정할 수 있습니다.
- 사용자> LoginUser, AppUser, SystemUser, CMSUser, …
또는 악명 높은 대괄호 [User]를 사용하십시오
답변
객체 관계형 매핑 도구를 사용하거나 향후에 Singular를 제안 합니다.
LLBLGen과 같은 일부 도구는 테이블 이름 자체를 변경하지 않고 Users to User와 같은 복수 이름을 자동으로 수정할 수 있습니다. 이것이 왜 중요한가? 매핑 할 때 코드에서 혼란스러워하는 tblUsers.strName이라는 이름의 오래된 데이터베이스 테이블에서 Users.Name 대신 User.Name 또는 User.Name처럼 보이기를 원하기 때문입니다.
나의 새로운 경험 법칙은 그것이 객체로 변환되면 어떻게 보일지를 판단하는 것입니다.
내가 찾은 새로운 이름에 맞지 않는 한 테이블은 UsersInRoles입니다. 그러나 항상 몇 가지 예외가 있으며이 경우에도 UsersInRoles.Username처럼 보입니다.
답변
나는 영어로 단수 인 무의미한 명사 를 사용하는 것을 선호합니다 .
테이블 이름의 수를 반영하면 다른 많은 답변이 보여주는 것처럼 직교 문제가 발생하지만 일반적으로 테이블에 여러 행이 포함되어 있기 때문에 선택적으로 구멍이 가득합니다. 대소 문자에 따라 명사를 구사하는 언어를 고려하면 더 분명합니다.
우리는 일반적으로 행으로 무언가를하고 있기 때문에 비난의 경우에 왜 이름을 넣지 않습니까? 우리가 읽은 것보다 더 많은 것을 쓰는 테이블이 있다면, 이름을 dative에 넣지 않겠습니까? 그것은 뭔가 의 표 입니다 . 왜 genitive를 사용하지 않습니까? 테이블은 상태 나 사용법에 관계없이 존재하는 추상 컨테이너로 정의되므로이를 수행하지 않습니다. 정확하고 절대적인 의미 론적 이유없이 명사를 활용하는 것은 당황스러운 일입니다.
무의미한 명사를 사용하는 것은 간단하고 논리적이며 규칙적이며 언어에 독립적입니다.
답변
테이블에 단수 이름이 필요한 규칙은 무엇입니까? 나는 항상 그것이 복수의 이름이라고 생각했다.
사용자가 사용자 테이블에 추가됩니다.
이 사이트는 다음에 동의합니다 :
http://vyaskn.tripod.com/object_naming.htm#Tables
이 사이트는 동의하지 않지만 동의하지는 않습니다 :
http://justinsomnia.org/writings/naming_conventions.html
다른 사람들이 언급했듯이 이것은 지침 일뿐입니다. 당신과 당신의 회사 / 프로젝트에 맞는 협약을 고르십시오. 단수형 또는 복수형 또는 간결한 단어 간을 전환하고 때로는 더 심하지 않은 경우가 있습니다.
답변
간단한 예로써 어떻습니까?
SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"
vs.
SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"
후자의 SQL은 전자보다 낯설다.
나는 단수 투표 .
답변
엔터티 관계 다이어그램에서 엔터티는 클래스 이름과 비슷한 단일 이름으로 반영되어야한다고 확신합니다. 인스턴스화되면 이름에 해당 인스턴스가 반영됩니다. 따라서 데이터베이스를 사용하면 테이블 (엔티티 또는 레코드 모음)으로 만들 때 엔터티가 여러 개가됩니다. 엔터티, 사용자는 테이블 사용자로 만들어집니다. 사용자 이름을 직원으로 향상시킬 수 있거나 귀하의 시나리오에 더 적합한 것을 제안한 다른 사람들에게 동의합니다.
레코드 그룹에서 선택하고 테이블 이름이 단수이면 잘 읽지 않기 때문에 SQL 문에서 더 의미가 있습니다.