sql 테이블 명명 딜레마 : 단수 대 복수 이름





15 Answers

나는 똑같은 질문을했고, 여기서 모든 대답을 읽은 후에 나는 단수의 이유와 함께 분명히 머물러있다.

이유 1 (개념). "AppleBag"과 같은 사과를 포함하는 가방을 생각할 수 있습니다. 0, 1 또는 100 만 개의 사과가 포함되어 있는지 여부는 중요하지 않습니다. 항상 같은 가방입니다. 테이블은 단지 컨테이너 일 뿐이므로 테이블 이름에는 포함 된 데이터의 양이 아니라 포함 된 내용을 설명해야합니다. 또한, 복수형 개념은 음성 언어에 관한 것입니다 (실제로 하나 이상의 언어가 있는지를 결정하는 것입니다).

이유 2 . (편의). 단수 이름을 사용하는 것이 복수형보다 쉽습니다. 객체는 불규칙한 복수형을 가질 수도 있고 복수형을 가질 수도 있습니다. 그러나 단 하나의 객체 만 가질 것입니다 (News와 같은 예외는 거의 없습니다).

  • 고객
  • 주문
  • 사용자
  • 지위
  • 뉴스

이유 3 . (미적 및 질서). 특히 마스터 - 세부 시나리오에서이 이름은 더 잘 읽고 이름이 더 잘 정렬되며 더 논리적 인 순서가 있습니다 (마스터 우선, 세부 두 번째).

  • 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]

sql sql-server naming-conventions

학계에서는 테이블 이름이 특성을 저장하는 엔티티의 단수이어야합니다.

나는 이름을 대괄호로 묶어야하는 T-SQL을 싫어하지만 Users 테이블의 이름을 단수로 변경하여 테이블을 사용하는 Users 가 대괄호를 사용해야하는 경우를 영원히 판결합니다.

내 직감은 단수로 머무르는 것이 더 옳다는 느낌이지만, 내 괄호는 공백이있는 열 이름과 같은 바람직하지 않은 것을 나타냅니다.

내가 머물러야합니까, 아니면 제가 가야합니까?




나는 영어로 단수가 아닌 무의미한 명사를 사용하는 것을 선호합니다.

테이블 이름의 수를 변경하면 정사영 문제 (많은 다른 답변이 표시하는 것처럼)가 발생하지만 테이블에 일반적으로 여러 행이 포함되어 있기 때문에 이렇게하는 것은 의미 적으로 구멍으로 가득차 있습니다. 사례를 기반으로 명사를 활용하는 언어를 고려해 볼 때 더 분명합니다 (대부분).

일반적으로 행을 가지고 뭔가를하고 있기 때문에 이름을 대소 문자에 넣지 않으시겠습니까? 우리가 읽는 것보다 더 많이 쓰는 테이블을 가지고 있다면 그 이름을 명사에 넣지 않으시겠습니까? 그것은 무언가의 테이블 입니다 , 왜 genitive를 사용하지 않습니까? 테이블은 상태 나 사용법에 관계없이 존재하는 추상 컨테이너로 정의되므로이 작업을 수행하지 않습니다. 정확하고 절대적인 의미 론적 이유없이 명사를 활용하는 것은 어색하다.

해석되지 않은 명사를 사용하는 것은 간단하고, 논리적이며, 규칙적이고 언어에 구애받지 않습니다.




이것에 대해 간단한 예를 들어 보겠습니다.

SELECT Customer.Name, Customer.Address FROM Customer WHERE Customer.Name > "def"

SELECT Customers.Name, Customers.Address FROM Customers WHERE Customers.Name > "def"

후자의 SQL은 전자의 것보다 낯선 것입니다.

나는 단수에 투표한다.




나는 테이블 이름과 프로그래밍 엔티티에 대해 단수로 고집한다.

이유? ⇒ 마우스양 ⇒ 양 처럼 영어로 불규칙한 복수형이 있다는 사실. 그런 다음 컬렉션이 필요한 경우 마우스 또는 양을 사용하고 계속 이동합니다.

그것은 정말로 다수가 눈에 띄는 것을 돕고, 나는 물건의 수집이 어떻게 생겼는지를 쉽게 그리고 프로그램 적으로 결정할 수 있습니다.

그래서, 제 규칙은 : 모든 것이 단수이며, 모든 사물의 수집은 단수이며, 덧붙여집니다. ORM에도 도움이됩니다.




나는 또한 복수형으로 가고, 앞서 언급 한 사용자 딜레마와 함께, 우리는 대괄호로 묶는 방식을 취한다.

우리는 데이터베이스 아키텍처와 응용 프로그램 아키텍처간에 일관성을 유지하기 위해이 작업을 수행합니다. 코드 테이블의 Users 컬렉션이 User 개체 컬렉션 인 경우 Users 테이블은 사용자 값 컬렉션이라는 기본 개념을 사용합니다.

데이터 팀과 개발자가 동일한 개념 언어 (항상 같은 객체 이름은 아님)를 사용하면 개발자간에 아이디어를 더 쉽게 전달할 수 있습니다.




단수형. 난 사용자 행 표현 개체 '사용자'의 무리를 포함하는 배열을 부르 겠지만, 테이블은 '사용자 테이블'입니다. 테이블에 포함 된 행 집합만으로 생각하면 IMO; 테이블이 메타 데이터이고 행 세트가 테이블에 계층 적으로 연결되어 있으면 테이블 자체가 아닙니다.

물론 ORM을 항상 사용하며 복수형 테이블 이름으로 작성된 ORM 코드가 어리석은 것으로 보입니다.




나는 영어로 된 명사가 (물, 수프, 현금) 셀 수 없을 때 (닭고기 대 닭고기, 고기 대 조류) 셀 수 없을 때 셀 수없이 많아지기 때문에 복수 표 이름을 좋아하지 않습니다. 나는 또한 테이블 이름이나 컬럼 이름에 대해 약어를 사용하는 것을 싫어한다. 왜냐하면 이미 그렇게 가파른 학습 곡선에 여분의 기울기가 추가되기 때문이다.

아이러니하게도, User (Transac-SQL) 때문에 User 를 예외로 만들고 User 라고 부르는 경우도 있습니다. 왜냐하면 필자는 테이블 주위에 대괄호를 사용하는 것을 좋아하지 않기 때문입니다.

나는 또한 모든 ID 열을 Id , ChickenId 또는 ChickensId 로 이름 ChickenId 것을 좋아하지 않습니다 (복수형은 무엇을합니까?).

이 모든 것은 데이터베이스 시스템에 대한 적절한 존중이 없기 때문에 Java's 습관과 게으름과 같은 OO 명명 규칙을 다시 적용하는 것입니다. 복잡한 SQL에 대한 IDE 지원이 개선되기를 바랍니다.




나는 실제로 항상 복수의 테이블 이름을 사용하는 것이 일반적인 규칙이라고 생각했습니다. 이 시점까지는 항상 복수형을 사용했습니다.

나는 단수의 테이블 이름에 대한 논쟁을 이해할 수 있지만 나에게는 복수형 이 더 적합합니다. 테이블 이름은 대개 테이블에 들어있는 내용을 설명합니다. 정규화 된 데이터베이스에서 각 테이블에는 특정 데이터 세트가 들어 있습니다. 각 행은 엔티티이고 테이블에는 많은 엔티티가 들어 있습니다. 따라서 테이블 이름에 대한 복수형.

자동차 테이블에는 자동차라는 이름이 있고 각 행은 자동차입니다. 필자는 table.field 방식으로 테이블을 필드와 함께 지정하는 것이 최상의 방법이며 단일 테이블 이름을 갖는 것이 더 읽기 쉽다는 것을 인정합니다. 그러나 다음 두 가지 예에서 전자는 더 의미가 있습니다.

SELECT * FROM cars WHERE color='blue'
SELECT * FROM car WHERE color='blue'

솔직히, 나는이 문제에 대한 내 입장을 다시 생각할 것이며, 내가 개발중인 조직이 사용하는 실제 협약에 의존 할 것이다. 그러나, 나는 내 개인적인 관습에 따라 여러 테이블 이름을 고수 할 것입니다. 내게는 더 의미가있다.




테이블 : 복수형

여러 사용자가 users 테이블에 나열됩니다.

모델 : 단수

단일 사용자는 users 테이블에서 선택할 수 있습니다.

컨트롤러 : 복수형

http://myapp.com/users 는 여러 사용자를 나열합니다.

그것은 어쨌든 그것을 받아들입니다.




내 테이크는 당신이 당신의 컨테이너를 어떻게 정의하는지에 따라 의미 론적이다. 예를 들어, "사과 주머니"또는 단순히 "사과"또는 "사과 주머니"또는 "사과".

예 : "대학"테이블에는 0 개 이상의 대학이 포함될 수 있습니다. "대학"테이블에는 0 명 이상의 동료가 포함될 수 있습니다.

a "student" table can contain 0 or more students 
a table of "students" can contain 0 or more students.

내 결론은 두 가지 중 어느 쪽이 좋지만 테이블을 참조 할 때 자신 (또는 그와 상호 작용하는 사람들)의 접근 방식을 정의해야한다는 것입니다. "도끼 테이블"또는 "xs 테이블"




다른 사람들이 언급했듯이, 규칙은 사용의 편의성과 가독성을 높이는 도구가되어야합니다. 개발자를 고문하는 족쇄 또는 클럽이 아닙니다.

즉, 개인적인 선호는 테이블과 컬럼 모두에 대해 단일 이름을 사용하는 것입니다. 이것은 아마도 내 프로그래밍 배경에서 온 것입니다. 클래스 이름은 일종의 컬렉션이 아니면 일반적으로 단수입니다. 내 마음 속에는 문제의 테이블에 개별 레코드를 저장하거나 읽으므로 단수로 나에게 의미가 있습니다.

이 연습을 통해 내 개체간에 다 대다 관계를 저장하는 테이블 이름을 여러 개 예약 할 수도 있습니다.

나는 테이블과 칼럼 이름에도 예약어를 쓰지 않으려 고한다. 여기에서 문제의 경우 사용자의 예약어를 사용하는 테이블을 캡슐화해야하는 필요성을 피하기 위해 사용자가 단수형 규칙에 어긋나지 않도록하는 것이 좋습니다.

제한된 방식으로 접두사를 사용하는 것이 좋지만 (테이블 이름은 tbl, proc 이름은 sp_ 등) 많은 사람들이 혼란스러워한다고 생각합니다. 나는 또한 이름을 타이핑 할 때 _ 대신 항상 +를 치기 때문에 결국 CamelBack 이름을 선호한다. 많은 다른 사람들이 동의하지 않습니다.

다음은 명명 규칙 지침을위한 또 다른 좋은 링크입니다. http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

컨벤션에서 가장 중요한 요소는 문제의 데이터베이스와 상호 작용하는 사람들이 이해할 수 있다는 것입니다. 명명 규칙에 관해서는 "모두를 다스리는 하나의 고리"가 없습니다.




단수로 사용하는 것은 대학에서 배운 것입니다. 그러나 동시에 객체 지향 프로그래밍과 달리 테이블은 레코드의 인스턴스가 아니라고 주장 할 있습니다.

나는 영어로 복수의 부정이 있기 때문에 나는 단수에 찬성하여 팁을주고 있다고 생각한다. 독일어의 경우 일관성있는 복수형으로 인해 더욱 악화됩니다. - 단어가 복수인지 아닌지 알 수없는 경우가 있습니다 (앞에 / die / das). 그리고 중국어에는 어쨌든 복수형이 없습니다.




한 번 User 테이블에 "Dude"를 사용했습니다. 동일한 짧은 문자 수, 키워드와의 충돌, 여전히 일반적인 사람에 대한 참조입니다. 코드를 볼 수있는 멍청한 머리를 염려하지 않는다면, 나는 그렇게했을 것입니다.




단수인지 복수인지에 관계없이 동일한 표기가 사용 된 테이블 이름에 대해서만 명사를 사용합니다.

사슴 물고기 사슴 항공기 당신은 바지 반바지 가위 종 자손




테이블의 SQL 정의는 실제로 컬렉션이 아닌 테이블의 잠재적 행 하나에 대한 정의입니다. 따라서 해당 정의에 사용 된 이름은] 렉션의 이름이 아닌 행의 유형을 지정해야합니다. 영어 문장에서 잘 읽혀 복수형을 선호하는 사람들은 논리적으로 생각하기 시작하고 실제로 테이블을 사용하는 것과 관련된 모든 논리 및 프로그래밍 코드를 살펴볼 필요가 있습니다. 단 하나의 테이블 이름을 사용하기 위해이 주석에서 언급 된 몇 가지 아주 좋은 이유가 있습니다. 여기에는 복수의 테이블 이름을 사용하지 않는 아주 좋은 이유가 포함됩니다. "잘 읽는 것"은 어떤 이유도해서는 안됩니다. 특히 어떤 사람들은 그 생각을 다르게 읽을 수 있기 때문입니다.




Related