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




sql-server naming-conventions (25)

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

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

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

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


Answers

단수형. 나는 가장 논리적 인 논점을 구입하지 않는다. 모든 사람들은 자신의 선호가 가장 논리적이라고 생각한다. 당신이하는 일이 무엇이든 상관없이, 단지 대회를 고수하고 그것에 충실하십시오. 고도로 불규칙한 문법과 의미 (정상적인 구어체와 문어체)를 가진 언어를 매우 특수한 의미론을 가진 매우 규칙적인 (SQL) 문법으로 매핑하려고합니다.

나의 주요 주장은 내가 테이블을 세트로 생각하지 않고 관계로 생각한다는 것이다.

따라서 AppUser 관계는 어떤 엔티티가 AppUsers 알려줍니다.

AppUserGroup 관계는 어떤 엔터티가 AppUserGroups 알려줍니다.

AppUser_AppUserGroup 관계는 AppUsersAppUserGroups 이 어떻게 관련되어 있는지 알려줍니다.

AppUserGroup_AppUserGroup 관계는 AppUserGroupsAppUserGroups 이 어떻게 관련되어 있는지 알려줍니다 (즉, 그룹의 그룹 구성원).

다시 말해, 엔티티와 그 엔티티가 어떻게 연관되어 있는지 생각할 때, 관계를 단수로 생각합니다. 물론 엔 엔티티를 콜렉션 또는 세트로 생각할 때 콜렉션 또는 세트는 복수입니다.

그런 다음 내 코드와 데이터베이스 스키마에서 단수를 사용합니다. 텍스트 설명에서 필자는 가독성을 높이기 위해 복수형을 사용하고 결국 글꼴 / 등을 사용하여 테이블 / 관계 이름을 복수형과 구별합니다.

저는 그것을 지저분하고 체계적으로 생각하고 싶습니다. 그리고 이런 방식으로, 표현하고자하는 관계에 대해 체계적으로 생성 된 이름이 항상 있습니다. 이것은 나에게 매우 중요합니다.


나는 항상 그것이 멍청한 대회라고 생각했다. 나는 복수의 테이블 이름을 사용한다.

(나는 그 정책의 합리적인 이유는 ORM 코드 생성기가 단수 이름에서 복수 이름을 생성하는 것이 더 쉽기 때문에 객체 및 컬렉션 클래스를 생성하는 것이 더 쉽다는 것입니다)


나는 그들이 단 하나의 테이블 이름을 좋아하기 때문에 CASE 구문을 사용하여 ER 다이어그램을 읽기 쉽게 만들었지 만 이러한 응답을 읽음으로써 나는 결코 잘 잡히지 않았다는 느낌을 받고있다. 나는 그것을 개인적으로 좋아한다. 단수의 테이블 이름을 사용하고 관계에 동작 동사를 추가하고 모든 관계에 대해 좋은 문장을 작성할 때 모델이 얼마나 읽기 쉬운 지에 대한 예제가있는 좋은 개요가 있습니다. 그것은 20 테이블 데이터베이스에 대한 과잉의 모든 비트지만 당신은 테이블의 수백과 복잡한 디자인 DB를 가지고 있다면 개발자가 어떻게 좋은 읽을 수있는 다이어그램없이 그것을 이해할 것인가?

http://www.aisintl.com/case/method.html

테이블과 접두어 접두어에 관해서는 나는 그 연습을 절대 싫어한다. 정보를 제공하기 전에 정보를 제공하지 마십시오. 누구든지 db 개체를 탐색하면 테이블을 뷰에서 쉽게 알 수 있습니다. 그러나 tblUsers라는 테이블이 있으면 어떤 이유로 나중에 두 테이블로 재구성하기로 결정하고 오래된 코드를 손상시키지 않도록 통합하는보기를 사용합니다 이제 tblUsers라는보기가 있습니다. 이 시점에서 나는 두 가지 매력적인 옵션을 남겨두고 일부 개발자를 혼란스럽게하는 tbl 접두사로 이름이 지정된 뷰를 남겨 두거나 중간 계층 또는 응용 프로그램을 다시 작성하여 새 구조 또는 이름 viewUsers를 참조하도록합니다. 그것은 IMHO 뷰의 가치의 상당 부분을 무효화합니다.


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

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

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

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

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

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

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


가능한 대안 :

  • SystemUser 테이블의 이름 바꾸기
  • 괄호 사용
  • 복수 테이블 이름을 유지하십시오.

브래킷을 사용하는 IMO는 기술적으로 가장 안전한 접근 방법이지만 조금 번거 롭습니다. IMO는 6 개 중 6 개이고 다른 솔루션은 솔루션이 개인 / 팀 환경에 달려 있습니다.


테이블 : 복수형

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

모델 : 단수

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

컨트롤러 : 복수형

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

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


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

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

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


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

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

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

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


우리는 이름을 스크립팅 할 때 유사한 표준을 실행합니다. 적절한 스키마 한정자 - 주로 SQL 구문을 사용하여 미래의 이름 붙이기에 대해 위험을 피합니다.

SELECT [Name] FROM [dbo].[Customer] WHERE [Location] = 'WA'

이것은 우리의 영혼을 과거에 구해 냈습니다. 우리 데이터베이스 시스템 중 일부는 SQL 6.0에서 SQL 2005까지 10 년 이상 수명이 흘렀습니다.


나는 그것이 내가 배운 것이기 때문에 항상 단수를 사용했습니다. 그러나 오랜 시간에 처음으로 새 스키마를 만드는 동안이 컨벤션을 유지하기로 결정했습니다 ... 간단합니다. 모든 테이블 이름의 끝에 's'를 추가하는 것은 모든 사람 앞에서 'tbl_'을 추가하는 것으로 쓸모없는 것처럼 보입니다.


필자는 개인적으로 복수의 이름을 사용하여 집합을 표현하는 것을 좋아하지만, 그것은 내 관계의 마음에 더 잘 들린다.

이 정확한 순간에 나는 회사의 데이터 모델을 정의하기 위해 단수 이름을 사용하고 있습니다. 왜냐하면 대부분의 사람들이 직장에서의 편견을 느끼기 때문입니다. 때로는 개인적인 취향을 부과하는 대신 모든 사람에게보다 쉽게 ​​삶을 만들어야합니다. (그게 내가이 스레드에서 결국 테이블 이름 지정을위한 "우수 사례"가되어야하는지에 대한 확인을 얻은 것입니다)

이 스레드에서 논쟁을 모두 읽은 후, 나는 결론에 도달 :

나는 모두가 좋아하는 풍미가 무엇이든, 여보와 함께 내 팬케이크를 좋아한다. 그러나 내가 다른 사람들을 위해 요리한다면, 나는 그들에게 그들이 좋아하는 것을 제공하려고 노력할 것이다.


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

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


MS SQL Server's시스템 테이블 을 보면 Microsoft에서 할당 한 이름이 있습니다 plural.

오라클의 시스템 테이블은에서 이름이 지정됩니다 singular. 그들 중 몇 개는 복수이지만. 오라클은 사용자 정의 테이블 이름에 대해 복수를 권장합니다. 그것은 그들이 한 가지를 추천하고 다른 것을 따르는 것이별로 의미가 없습니다. 이 두 거대 소프트웨어 거장의 건축가가 다른 표기법을 사용하여 테이블의 이름을 지었다고해도별로 의미가 없으므로 ... 결국이 사람들은 ... 박사님은 뭐니?

나는 학계에서 기억하고있다. 추천은 단수이다.

예를 들어, 우리가 말할 때 :

select OrderHeader.ID FROM OrderHeader WHERE OrderHeader.Reference = 'ABC123'

어쩌면 b / c 각각 ID특정 단일 행에서 선택 ...?


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

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


다른 사람들은 "표준"에 관한 한 꽤 좋은 답변을 해왔지만, 나는 이것을 추가하고 싶었습니다 ... "사용자"(또는 "사용자")가 실제로 테이블에 보관 된 데이터의 완전한 설명이 아닐 수 있습니까? ? 테이블 이름과 특이성에 너무 익숙하지 않아도 "Widget_Users"(여기서 "위젯"은 응용 프로그램이나 웹 사이트의 이름 임)과 같은 것이 더 적합 할 것입니다.


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

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


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

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

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

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


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


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

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

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

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


IMHO, 테이블 이름은 고객 과 같이 복수 여야합니다.

클래스 이름은 Customers 테이블의 행에 매핑되는 경우 Customer 와 같이 단수이어야합니다.


시스템 tables/views서버 자체 (의 SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, 등) 거의 항상 복수입니다. 나는 그들의 단서를 따라야 할 일관성을 위해서라고 생각합니다.


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

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

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

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


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


이것은 약간 중복 될 수 있지만 신중할 것을 제안합니다. 테이블 이름을 바꾸는 것은 나쁜 일은 아니지만 표준화는 바로 그 것이다. 표준 -이 데이터베이스는 이미 "표준화"되어있을 수도 있지만 나쁘지는 않습니다.) -이 데이터베이스가 이미 존재하고 아마도 2 개 이상의 테이블로 구성되어 있기 때문에 더 나은 목표로 일관성을 제안 할 것입니다.

전체 데이터베이스를 표준화하거나 적어도 끝까지 작업을 계획하고 있지 않다면, 테이블 이름이 빙산의 일각에 지나지 않으며, 당면 과제에 집중하고, 불명확 한 객체의 고통을 견디며, 당신의 최대 관심사 -

실용적인 일관성이 때로는 최고의 표준입니다 ... :)

my2cents ---


Wheat의 답변은 좋지만 모든 스키마 또는 데이터베이스에서 동일한 테이블 이름 / 열 이름 쌍이 없다고 가정합니다. 그 상태를 안전하게 사용하려면 다음을 사용하십시오 ...

select *
from Information_Schema.Columns
where Table_Catalog = 'DatabaseName'
  and Table_Schema = 'SchemaName'
  and Table_Name = 'TableName'
  and Column_Name = 'ColumnName'




sql sql-server naming-conventions