[SQL] 표 명명 딜레마 : 단수 복수 대 이름 [폐쇄]

표 명명 딜레마 : 단수 복수 대 이름 [폐쇄]

학계는 테이블 이름들이의 속성을 저장하는 엔티티의 단수해야 그것이있다.

나는 이름을 대괄호를 필요로하는 T-SQL을 싫어하지만 난 영원히 가끔 괄호를 사용해야에 테이블을 사용하는 사람들을 선고, 단수에 사용자 테이블의 이름을 변경했다.

내 직감 느낌은 단수와 함께 머물 것이 더 정확하지만 내 직감 느낌이 괄호 그들 등에 공백이 열 이름과 같은 바람직하지 않은 사람을 나타내는 것이 있다는 것이다

나는있을 경우, 또는 내가 가야하나요?

해결법

1. ==============================

   1.기타까지 "표준"이동 등으로 꽤 좋은 답을 준,하지만 난 그냥이 추가 싶어 ... "사용자"(또는 "사용자") 테이블에있는 데이터에 대한 자세한 설명이되어 있지 않은 것으로 있다고 그것을 가능 ? 당신은 같은 테이블 이름과 특이성, 그러나 아마 뭔가 너무 미친해야하지 않는 것이 "Widget_Users"더 적합 할 것 ( "위젯"응용 프로그램 또는 웹 사이트의 이름입니다).

   기타까지 "표준"이동 등으로 꽤 좋은 답을 준,하지만 난 그냥이 추가 싶어 ... "사용자"(또는 "사용자") 테이블에있는 데이터에 대한 자세한 설명이되어 있지 않은 것으로 있다고 그것을 가능 ? 당신은 같은 테이블 이름과 특이성, 그러나 아마 뭔가 너무 미친해야하지 않는 것이 "Widget_Users"더 적합 할 것 ( "위젯"응용 프로그램 또는 웹 사이트의 이름입니다).

2. ==============================

   2.나는 같은 질문을했고, 여기에 모든 대답을 읽은 후 나는 확실히 단수, 이유와 함께 머물 :

   나는 같은 질문을했고, 여기에 모든 대답을 읽은 후 나는 확실히 단수, 이유와 함께 머물 :

   이유 1 (개념). 0, 1 백만 사과 포함 된 경우는 "AppleBag"와 같은 사과를 포함 가방 생각할 수있는, 그것은 중요하지 않습니다, 그것은 항상 같은 가방입니다. 테이블, 컨테이너, 테이블 이름이 포함되지 얼마나 많은 데이터가 포함 된 내용을 설명해야 그냥 있습니다. 또한, 복수의 개념은 더 많은 음성 언어 중 하나에 대한 것입니다 (실제로는 하나 또는 그 이상의 존재 여부를 확인하는).

   이유 2. (편의점). 그것은 쉽게 복수의 사람보다, 단수 이름으로 나와있다. 객체는 전혀 복수의 불규칙 복수형 여부를 가질 수 있지만, 항상 (뉴스 같은 몇 가지 예외를 제외하고) 단수를해야합니다.

   이유 3. (미용 및 주문). 특히 마스터 상세 시나리오에서,이 (제 1 마스터 상세 초) 이름으로 더 나은 초침 판독하고,보다 논리적 순서를 가지고

   에 비해 :

   이유 4 (단순). 모두 함께 넣어, 테이블 이름, 기본 키, 관계, 엔티티 클래스 ... 단 하나의 이름 (단수) 대신 두 (단수 클래스, 복수의 테이블, 단수 필드, 단수 - 복수 마스터 - 세부 사항을 알고 있어야하는 것이 좋습니다 .. .)

   당신은 당신이 "고객"으로 다루고 알게되면, 당신은 당신이 당신의 데이터베이스 상호 작용의 모든 요구에 대해 동일한 단어를 사용 할 수 있습니다.

   이유 5. (세계화). 세계는 작아지고, 서로 다른 국적의 팀을 보유하고 있고, 모든 사람은 영어를 기본 언어로 있습니다. 비 네이티브 영어 프로그래머 대신 "에서 상태"보다는 "저장소"의 "저장소"또는 "상태"생각하기가 쉬울 것이다. 생각하는 필요가 없으므로 시간 저장, 오타로 인한 적은 오류가 발생할 수있는 유일한 이름을 갖는 "그것은 자녀 또는 아동인가?", 따라서 생산성을 향상시킬 수있다.

   이유 6. (왜?). 그것은 심지어 디스크 공간을 저장, 당신은 시간을 쓰고 저장하고, 심지어 더 오래 컴퓨터 키보드를 만들 수 있습니다!

   당신은 세 글자, 3 바이트, 3 여분의 키보드 안타를 저장 한 :)

   그리고 마지막으로, 당신은 같은 예약 된 이름을 엉망으로 그 사람의 이름을 지정할 수 있습니다 :

   또는 악명 높은 대괄호 [사용자]를 사용

3. ==============================

   3.향후 객체 관계형 매핑 도구 나 의지를 사용하는 경우 나는 단수를 제안한다.

   향후 객체 관계형 매핑 도구 나 의지를 사용하는 경우 나는 단수를 제안한다.

   LLBLGen 같은 일부 도구는 자동으로 올바른 복수의 이름은 테이블 이름 자체를 변경하지 않고 사용자에게 사용자를 좋아 할 수 있습니다. 왜이 일을 하는가? 이 매핑 된 때 때문에, 당신은 단지 코드에서 혼란 tblUsers.strName 명명 내 옛 데이터베이스 테이블의 일부에서 User.Name 대신 Users.Name 또는 더 나쁜처럼 보이도록합니다.

   엄지 내 새 규칙은이 개체로 변환되어있어 일단 모양을 어떻게 판단하는 것입니다.

   새로운 명명 I 사용에 맞지 않는 내가 찾은 하나 개의 테이블은 UsersInRoles입니다. 하지만 항상 그 몇 가지 예외를 제외하고이 경우에도 그것은 UsersInRoles.Username로 벌금을 보이는 것입니다.

4. ==============================

   4.나는 단수 될 일이 영어로 어형 명사를 사용하는 것을 선호합니다.

   나는 단수 될 일이 영어로 어형 명사를 사용하는 것을 선호합니다.

   직교 문제가 테이블 이름의 수를 (다른 답변의 많은 등이 보여) 원인 Inflecting하지만 테이블은 일반적으로 여러 행을 포함하기 때문에 그렇게 선택하면 구멍의 의미 론적으로 가득 차있다. 우리가 inflects 명사 (대부분이처럼) 케이스를 기반으로하는 언어를 고려한다면 이는 더욱 분명하다 :

   우리가 일반적으로 행과 함께 일을하고 있기 때문에, 왜 대격 경우에 이름을 넣어하지? 우리는 우리가 우리가 더 읽기보다, 왜 여격에 이름을 넣지하기 위해 작성하는 테이블이 있다면? 소유격을 사용하지 이유는, 무언가의 표인가? 테이블에 관계없이 해당 상태 나 사용의 존재 추상 컨테이너로 정의되어 있기 때문에 우리는이 작업을 수행하지 않을 것입니다. 정확한 절대 의미 이유없이 명사 Inflecting 것은 재잘이다.

   어형 명사를 사용하면 간단한 논리, 정규 및 언어에 독립적이다.

5. ==============================

   5.어떤 규칙은 테이블이 단수 이름이 있어야합니다? 나는 항상 복수의 이름을 생각했다.

   어떤 규칙은 테이블이 단수 이름이 있어야합니다? 나는 항상 복수의 이름을 생각했다.

   사용자는 사용자 테이블에 추가됩니다.

   이 사이트는 동의한다 : http://vyaskn.tripod.com/object_naming.htm#Tables

   이 사이트에 동의하지 (그러나 나는 그것을 동의) : http://justinsomnia.org/writings/naming_conventions.html

   다른 언급이 : 이건 그냥 지침입니다. 당신과 그것으로 귀하의 회사 / 프로젝트와 스틱 작동하는 규칙을 선택합니다. 단수 및 복수 또는 때로는 축약 단어와 때로는하지 사이의 전환은 훨씬 더 악화입니다.

6. ==============================

   6.이 방법에 대해 간단한 예로서 :

   이 방법에 대해 간단한 예로서 :

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

   대

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

   후자의 SQL은 이전보다 소리가 나는 낯선 사람이다.

   단수에 난 투표.

7. ==============================

   7.나는 엔티티 관계 다이어그램에서, 엔티티가 클래스 이름은 단수되는 유사한 단수 이름으로 반영되어야한다는 확고한 신념입니다. 인스턴스화되면, 이름은 인스턴스를 반영한다. 따라서 데이터베이스와 테이블 (개체 또는 레코드 컬렉션)로 만든 기업은 복수입니다. 엔티티는, 사용자는 테이블 사용자로 이루어진다. 나는 아마 이름을 사용자가 직원이나 시나리오에 더 적용 뭔가 개선 할 수있는 제안 다른 사람과 동의 할 것입니다.

   나는 엔티티 관계 다이어그램에서, 엔티티가 클래스 이름은 단수되는 유사한 단수 이름으로 반영되어야한다는 확고한 신념입니다. 인스턴스화되면, 이름은 인스턴스를 반영한다. 따라서 데이터베이스와 테이블 (개체 또는 레코드 컬렉션)로 만든 기업은 복수입니다. 엔티티는, 사용자는 테이블 사용자로 이루어진다. 나는 아마 이름을 사용자가 직원이나 시나리오에 더 적용 뭔가 개선 할 수있는 제안 다른 사람과 동의 할 것입니다.

   당신이 레코드 그룹에서 선택되기 때문 다음 SQL 문에 더 의미하고 테이블 이름은 단수 인 경우, 그것은 잘 읽지 않습니다.

8. ==============================

   8.나는 테이블 이름에 대한 단수 및 프로그래밍 엔티티와 막대기.

   나는 테이블 이름에 대한 단수 및 프로그래밍 엔티티와 막대기.

   이유? 마우스 ⇒ 마우스와 양 ⇒ 양처럼 영어 불규칙 복수형이 있다는 사실. 내가 컬렉션을 필요로하는 경우 그리고, 난 그냥 마우스를 올리면 또는 양을 사용하고 이동합니다.

   정말 복수가 눈에 띄는 데 도움이, 나는 쉽게 프로그래밍 방식으로 사물의 수집이 어떻게 보이는지 확인할 수 있습니다.

   그래서, 내 규칙이 있습니다 : 모든 단수, 사물의 모든 컬렉션에 추가는 S와 단수입니다. 너무으로 ORMs에 도움이됩니다.

9. ==============================

   9.이럴 테이블 이름은 고객과 같은 복수해야한다.

   이럴 테이블 이름은 고객과 같은 복수해야한다.

   는 고객 테이블의 행에 매핑하고있는 경우 클래스 이름은 고객과 같은 단수해야한다.

10. ==============================

    10.단수형. 모든 사람은 자신의 선호가 가장 논리적 인 생각 - 내가 가장 논리적 인 관련된 모든 인수를 구입하지 않습니다. 당신이 엉망 무슨 상관없이, 단지에 대한 규칙 및 스틱을 선택합니다. 우리는 매우 특별한 의미를 가진 매우 일반 (SQL) 문법에 매우 불규칙한 문법과 의미 (일반 음성 및 문자 언어)와 언어지도를 위해 노력하고 있습니다.

    단수형. 모든 사람은 자신의 선호가 가장 논리적 인 생각 - 내가 가장 논리적 인 관련된 모든 인수를 구입하지 않습니다. 당신이 엉망 무슨 상관없이, 단지에 대한 규칙 및 스틱을 선택합니다. 우리는 매우 특별한 의미를 가진 매우 일반 (SQL) 문법에 매우 불규칙한 문법과 의미 (일반 음성 및 문자 언어)와 언어지도를 위해 노력하고 있습니다.

    내 주요 인수는 내가 한 세트 만 관계로 테이블로 생각하지 않는다는 것입니다.

    그래서, APPUSER 관계는 실체가 AppUsers있는 알려줍니다.

    AppUserGroup 관계는 엔티티 AppUserGroups이있는 저에게 말한다

    AppUser_AppUserGroup의 관계는 AppUsers 및 AppUserGroups이 어떻게 관련되는지를 알려줍니다.

    AppUserGroup_AppUserGroup 관계는 AppUserGroups 및 AppUserGroups은 (그룹 즉 그룹의 멤버)와 관련되는 방법을 알려줍니다.

    즉, 나는 실체에 대해 생각할 때 그들이 관련되어 어떻게 단수의 관계를 생각,하지만 난 컬렉션 또는 세트의 실체 생각하면 물론, 컬렉션 또는 세트는 복수입니다.

    내 코드에서, 다음, 데이터베이스 스키마에, 나는 단수 사용합니다. 텍스트 설명에서, 나는이 증가 가독성을 위해 복수를 사용하게 - 다음 복수의에서 테이블 / 관계 이름을 구별하는 글꼴 등을 사용합니다.

    나는 지저분한으로 생각하기 좋아하지만 체계적인 -이 방법은 항상 내가 매우 중요하다 나에게하는 표현하고자 관계에 대해 체계적으로 생성 된 이름이 있습니다.

11. ==============================

    11.나는 또한 복수형 함께 갈 것이며, 상기 사용자의 딜레마, 우리는 광장 브라케팅 접근 방식을 않습니다.

    나는 또한 복수형 함께 갈 것이며, 상기 사용자의 딜레마, 우리는 광장 브라케팅 접근 방식을 않습니다.

    우리는 코드 이슈에서 사용자 컬렉션으로 많은 사용자 개체의 컬렉션으로 사용자 테이블에 사용자 값의 집합이라는 기본 이해,이 데이터베이스 아키텍처와 애플리케이션 아키텍처 둘 사이의 균일 성을 제공하기 위해 않습니다.

    같은 개념 언어 (비록 항상 같은 개체 이름)을 말하는 우리의 데이터 팀과 우리의 개발자를 갖는 것은 쉽게 그들 사이의 아이디어를 전달 할 수 있습니다.

12. ==============================

    12.나는 개인적으로 내 합리적인 마음에 더 집합을 표현하기 위해 복수의 이름을 사용하도록 그냥 "소리"를 선호합니다.

    나는 개인적으로 내 합리적인 마음에 더 집합을 표현하기 위해 복수의 이름을 사용하도록 그냥 "소리"를 선호합니다.

    직장에서 대부분의 사람들이 더 편하지 느끼기 때문에이 정확한 순간에 나는 내 회사에 대한 데이터 모델을 정의하는 단일 이름을 사용하고 있습니다. 가끔은 그냥 대신 귀하의 개인 환경 설정을 부과의 모든 사람의 인생을 더 쉽게해야한다. (난이 스레드에 결국 방법의는 테이블 이름에 대해 "가장 좋은 방법"으로해야하는지에 대한 확인을 얻을 수 있음)

    이 스레드에있는 모든 논쟁을 읽은 후, 나는 하나의 결론에 도달 :

    나는 꿀, 모두가 좋아하는 맛이 무엇인지에 상관없이 내 팬케이크를 좋아한다. 내가 다른 사람을 위해 요리하고 경우에, 나는 그들이 원하는 그 무언가를 제공하기 위해 노력할 것입니다.

13. ==============================

    13.단수형. 나는 사용자 행 표현 개체를 '사용자'의 무리를 포함한 배열이 전화 싶지만, 테이블은 '사용자 테이블'입니다. 아무것도하지만이 IMO, 잘못이 포함 된 행 세트 인하지 않기 때문에 테이블을 생각; 테이블은 테이블 자체가 아니라, 메타 데이터, 그리고 행 세트는 계층 적 테이블에 부착된다.

    단수형. 나는 사용자 행 표현 개체를 '사용자'의 무리를 포함한 배열이 전화 싶지만, 테이블은 '사용자 테이블'입니다. 아무것도하지만이 IMO, 잘못이 포함 된 행 세트 인하지 않기 때문에 테이블을 생각; 테이블은 테이블 자체가 아니라, 메타 데이터, 그리고 행 세트는 계층 적 테이블에 부착된다.

    나는 물론, ORM들을 모든 시간을 사용하고 복수 테이블 이름으로 기록 된 ORM 코드가 바보 보이는 데 도움이됩니다.

14. ==============================

    14.사실은 항상 복수의 테이블 이름을 사용하는 인기있는 대회라고 생각했습니다. 이 시점까지는 나는 항상 복수를 사용했습니다.

    사실은 항상 복수의 테이블 이름을 사용하는 인기있는 대회라고 생각했습니다. 이 시점까지는 나는 항상 복수를 사용했습니다.

    나는 단수 테이블 이름의 인수를 이해하지만, 나에게 복수 더 의미가 있습니다. 테이블 이름은 일반적으로 테이블에 포함 된 내용을 설명합니다. 정규화 데이터베이스에서, 각각의 테이블은 특정 데이터 세트를 포함한다. 각 행은 엔티티이고 테이블은 많은 개체가 포함되어 있습니다. 따라서 테이블 이름의 복수형.

    자동차의 테이블은 이름이 차있을 것입니다 각 행은 차다. 나는 table.field 방식의 필드와 함께 테이블을 지정하는 것이 가장 좋은 방법입니다 및 단수 테이블 이름을 가진 것이 더 읽을 수 있음을 인정한다. 그러나 다음과 같은 두 가지 예에서, 전 차종 더 의미 :

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

    솔직히, 나는이 문제에 내 위치를 다시 생각한다, 나는 I가 개발하고 있어요 조직에 의해 사용되는 실제 규칙에 의존하는 것이다. 그러나, 나는 내 개인 컨벤션, 나는 복수의 테이블 이름을 고수 것 같아요. 나에게 그것은 더 의미가 있습니다.

15. ==============================

    15.영어로 일부 명사 (물, 스프, 현금) 가산하지 않거나 당신이 그것을 셀 수 할 때 의미가 변화 때문에 복수의 테이블 이름처럼하지 않습니다 (닭 대 닭, 고기, 조류 대). 그렇게하는 이미 가파른 학습 곡선에 여분의 경사를 추가하기 때문에 나는 또한 테이블 이름 또는 열 이름을 사용하는 약어를 싫어한다.

    영어로 일부 명사 (물, 스프, 현금) 가산하지 않거나 당신이 그것을 셀 수 할 때 의미가 변화 때문에 복수의 테이블 이름처럼하지 않습니다 (닭 대 닭, 고기, 조류 대). 그렇게하는 이미 가파른 학습 곡선에 여분의 경사를 추가하기 때문에 나는 또한 테이블 이름 또는 열 이름을 사용하는 약어를 싫어한다.

    아이러니하게도, 나는 사용자 예외를 만들 수 있으며 내가 너무 I가없는 경우 테이블 주위에 괄호를 사용하는 것과하지 않기 때문에, 때문에 USER (TRANSAC-SQL)의 IT 사용자를 호출합니다.

    또한 같은 I 이드하지 ChickenId 또는 ChickensId 같은 모든 ID 열 이름을 지정합니다 (복수의 사람이 이것에 대해 어떻게 무엇을?).

    자바 습관과 게으름 밖으로처럼 나는 데이터베이스 시스템에 대한 적절한 존중하지 않기 때문에 이것이 모두, 난 그냥 OO 명명 규칙에서 한 트릭 - 조랑말 지식을 다시 적용하고있다. 나는 복잡한 SQL에 대한 더 나은 IDE 지원이 있었다 바랍니다.

16. ==============================

    16.우리는 적절한 스키마 예선을 우리가 이름 주위에 [] 요구 스크립팅 할 때, 유사한 기준을 실행 한 경우 - 주로 그것은 SQL 구문에 의해 미래의 이름 횡령에 대해 베팅을 헤지.

    우리는 적절한 스키마 예선을 우리가 이름 주위에 [] 요구 스크립팅 할 때, 유사한 기준을 실행 한 경우 - 주로 그것은 SQL 구문에 의해 미래의 이름 횡령에 대해 베팅을 헤지.

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

    이것은 과거에 우리의 영혼을 저장 한 - 방법 의도 수명 과거 - 우리의 데이터베이스 시스템의 일부는 2005 SQL을 통해 SQL 6.0에서 10 년을 실행했다.

17. ==============================

    17.테이블 : 복수

    테이블 : 복수

    모델 : 단수

    컨트롤러 : 복수

    즉 어쨌든에 내 걸릴입니다.

18. ==============================

    18.그들은 내 ER 다이어그램을 쉽게 읽을 CASE 구문을 사용하게 나는,하지만 나는 그것을 아주 잘 잡은 적이 느낌을 받고있어 이러한 응답을 읽어 단수 테이블 이름의 팬입니까? 나는 개인적으로 그것을 사랑 해요. 당신의 모델은 단일 테이블 이름을 사용하는 경우, 수있는 모든 관계에 대한 관계 및 양식 좋은 문장에 액션 동사를 추가하는 방법을 읽을 수의 예제와 함께 좋은 개요가있다. 그것은 20 테이블 데이터베이스에 대한 모든 과잉의 약간의 그러나 당신이 테이블의 수백 복잡한 설계와 DB가 있다면 방법 개발자는 지금까지 좋은 읽을도없이 그것을 이해할 것인가?

    그들은 내 ER 다이어그램을 쉽게 읽을 CASE 구문을 사용하게 나는,하지만 나는 그것을 아주 잘 잡은 적이 느낌을 받고있어 이러한 응답을 읽어 단수 테이블 이름의 팬입니까? 나는 개인적으로 그것을 사랑 해요. 당신의 모델은 단일 테이블 이름을 사용하는 경우, 수있는 모든 관계에 대한 관계 및 양식 좋은 문장에 액션 동사를 추가하는 방법을 읽을 수의 예제와 함께 좋은 개요가있다. 그것은 20 테이블 데이터베이스에 대한 모든 과잉의 약간의 그러나 당신이 테이블의 수백 복잡한 설계와 DB가 있다면 방법 개발자는 지금까지 좋은 읽을도없이 그것을 이해할 것인가?

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

    테이블과 뷰를 접 두부에 관해서는 나는 절대적으로 그 연습을 싫어. 그들에게 가능성이 잘못된 정보를 제공하기 전에 사람에게 전혀 정보를 제공하지 않습니다. 객체에 대한 DB를 검색하는 사람은 아주 쉽게 뷰에서 테이블을 말할 수있는,하지만 난 테이블을 이름에 tblUsers이있는 경우 어떤 이유로 나는 예전의 코드를 깨는에서 계속을 통일 볼 수있는, 두 개의 테이블로 미래의 구조 조정에 결정하는 것이 지금은보기 이름에 tblUsers 있습니다. 나는이 호소력이 옵션 왼쪽하고이 시점에서, 중간 계층 또는 응용 프로그램 중 하나를 일부 개발자를 혼동, 또는 다른 계층을 강제 할 수 이는 TBL 접두사가 나의 새로운 구조 또는 이름 viewUsers을 참조하도록 다시 작성하기로라는 이름의보기를 둡니다. 즉, 전경을 Negate 이럴 값의 큰 부분.

19. ==============================

    19.시스템 테이블 / 서버 자체의 플레이 (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, INFORMATION_SCHEMA.COLUMNS 등) 거의 항상 복수입니다. 나는 우위를 따라 줄 일관성을 위해서 같아요.

    시스템 테이블 / 서버 자체의 플레이 (SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, INFORMATION_SCHEMA.COLUMNS 등) 거의 항상 복수입니다. 나는 우위를 따라 줄 일관성을 위해서 같아요.

20. ==============================

    20.우리가 MS SQL Server 시스템 테이블을 보면, 마이크로 소프트에 의해 할당 된 그들의 이름은 복수에 있습니다.

    우리가 MS SQL Server 시스템 테이블을 보면, 마이크로 소프트에 의해 할당 된 그들의 이름은 복수에 있습니다.

    오라클의 시스템 테이블은 단수에 이름이 지정됩니다. 그 중 몇 가지 있지만 복수입니다. 오라클은 사용자 정의 테이블 이름에 대한 복수 권장합니다. 그것이 그들이 한 가지를 추천하는 것이 더 의미가 다른를 수행하지 않습니다. 이 두 소프트웨어 거인의 건축가가 서로 다른 규칙을 사용하여 테이블 이름을 가지고, 많은 이해가되지 않습니다 중 하나 ... 결국,이 녀석 ... 박사의는 무엇인가?

    나는 학계에서 추천 단수이었다 기억 않습니다.

    예를 들어, 우리는 때를 말한다 :

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

    아마 B / C 각각의 ID는 특정한 하나의 행으로부터 선택되는 ...?

21. ==============================

    21.이것은 약간의 중복이 될 수 있지만, 나는 신중 건의 할 것입니다. 아니 반드시 테이블의 이름을 변경하는 나쁜 일이지만, 표준화 그냥이다; 표준 -이 데이터베이스는 이미 :) 그러나 심하게, "표준화"할 수있다 -이 데이터베이스가 이미 존재 함을 주어 더 나은 목표로 일관성을 제안하고 아마도 그것은 단지 2 테이블보다 더 구성되어 있습니다.

    이것은 약간의 중복이 될 수 있지만, 나는 신중 건의 할 것입니다. 아니 반드시 테이블의 이름을 변경하는 나쁜 일이지만, 표준화 그냥이다; 표준 -이 데이터베이스는 이미 :) 그러나 심하게, "표준화"할 수있다 -이 데이터베이스가 이미 존재 함을 주어 더 나은 목표로 일관성을 제안하고 아마도 그것은 단지 2 테이블보다 더 구성되어 있습니다.

    당신은 전체 데이터베이스를 표준화 할 수 있습니다, 또는 적어도 그 끝으로 작업을 계획하지 않는 한, 나는에있을 수 있습니다, 그 테이블 이름은 단지 빙산의 팁과 가난 명명 된 개체의 고통을 지속, 손 작업에 집중하고 있습니다 의심 당신의 최대 관심사 -

    실제 일관성은 때때로 ... 가장 좋은 표준입니다 :)

    my2cents ---

22. ==============================

    22.가능한 대안 :

    가능한 대안 :

    이 비트 복잡하지만 IMO, 기술적으로 가장 안전한 방법을 브래킷을한다 사용. IMO는 다른의 대여섯 6 일의, 그리고 솔루션 정말 그냥 개인 / 팀 선호로 귀결.

23. ==============================

    23.필자는 당신이 당신의 컨테이너를 정의하는 방법에 따라 의미입니다. 예를 들어, A 또는 단순히 "사과"또는 "애플 가방"또는 "사과" "사과의 가방".

    필자는 당신이 당신의 컨테이너를 정의하는 방법에 따라 의미입니다. 예를 들어, A 또는 단순히 "사과"또는 "애플 가방"또는 "사과" "사과의 가방".

    예:     는 "대학"표는 0 개 이상의 대학을 포함 할 수 있습니다     "대학"의 테이블은 0 개 이상의 동료들을 포함 할 수 있습니다

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

    내 결론은 하나가 잘이라고하지만 당신은 테이블을 참조 할 때 (또는 상호 작용 사람들이) 접근 방식에가는 방법을 정의 할 수있다; "는 X 표"또는 "XS의 표"

24. ==============================

    24.다른 사람이 여기에 언급 한대로, 규칙은 사용 및 가독성의 용이성에 추가하기위한 도구가 될 것이다. 아니 걸쇠 고문 개발자들에게 클럽으로.

    다른 사람이 여기에 언급 한대로, 규칙은 사용 및 가독성의 용이성에 추가하기위한 도구가 될 것이다. 아니 걸쇠 고문 개발자들에게 클럽으로.

    그건 내 개인적인 취향은 테이블과 열 모두 단수 이름을 사용하는 것입니다 말했다. 이것은 아마 내 프로그래밍 배경에서 비롯됩니다. 그들이 수집의 일종하지 않는 한 클래스 이름은 일반적으로 단수입니다. 단일 차종이 나에게 느낄 수 있도록, 내 마음에서 나는 저장하고 또는 문제의 테이블에 개별 레코드를 읽고.

    이 연습은 또한 내 객체 사이의 다 대다 관계를 저장하는 사람들을 위해 복수의 테이블 이름을 예약 할 수 있습니다.

    나뿐만 아니라, 내 테이블 및 열 이름에 예약어를 피하려고합니다. 이 사용자는 사용자의 예약어를 사용하는 테이블을 캡슐화 할 필요성을 방지하기 위해 단일 대회로 카운터 가서 더 많은 의미가 여기에 문제의 경우.

    내가 제한된 방식으로 접두사를 사용하는 것과 같습니다 (TBL 테이블 이름, PROC 이름에 대한 SP_ 등을 위해), 많은 생각하지만이 혼란을 추가합니다. 난 항상 이름을 입력 할 때 _ 대신 + 타격 결국 때문에 나는 또한 밑줄에 낙타의 이름을 선호합니다. 많은 사람들은 동의하지 않는다.

    다음은 이름 지정 규칙 지침에 대한 또 다른 좋은 링크는 다음과 같습니다 http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

    국제 대회에서 가장 중요한 요소는 문제의 데이터베이스와 상호 작용하는 사람들에게 의미가 있다는 것을 기억하십시오. "절대 반지는 모두 규칙에"아니오가이 명명 규칙에 올 때.

25. ==============================

    25.나는 단수를 사용하여 우리가 대학에서 배운 것입니다 생각합니다. 그러나 동시에 당신은 객체 지향 프로그래밍 달리 테이블이 기록의 인스턴스 아니라고 주장 할 수 있습니다.

    나는 단수를 사용하여 우리가 대학에서 배운 것입니다 생각합니다. 그러나 동시에 당신은 객체 지향 프로그래밍 달리 테이블이 기록의 인스턴스 아니라고 주장 할 수 있습니다.

    나는 때문에 영어로 복수의 부정의 순간에 단수에 찬성 팁 것 같아요. 독일어로 인한없이 일관된 복수 형태로 더 악화 - 때때로 당신은 단어가 복수의 여부를 그 (DER / 다이 / DAS)의 앞에 지정 기사없이인지 알 수 없습니다. 그리고 중국어 언어에는 복수 형태 어쨌든 없다.

26. ==============================

    26.문자 같은 짧은 번호, 키워드 충돌없이, 일반적인 인간에 여전히 참조 - 나는 한 번 사용자 테이블의 "야"를 사용했다. 내가 코드를 볼 수있는 답답한 머리에 대해 우려하지 않은 경우에, 나는 그런 식으로 유지했을 것이다.

    문자 같은 짧은 번호, 키워드 충돌없이, 일반적인 인간에 여전히 참조 - 나는 한 번 사용자 테이블의 "야"를 사용했다. 내가 코드를 볼 수있는 답답한 머리에 대해 우려하지 않은 경우에, 나는 그런 식으로 유지했을 것이다.

27. ==============================

    27.그게 내가 배운거야 간단하기 때문에 나는 항상 단수 사용했습니다. 최근에 새로운 스키마를 작성하는 동안 그러나, 오랜 시간에 처음으로, 나는 적극적으로 짧은 때문에 ... 단순히이 규칙을 유지하기로 결정했다. 모든 테이블 이름의 끝에 's'를 추가하면 모든 사람 앞에 'TBL_'를 추가하는 등 나에게 쓸모없는 것처럼 보인다.

    그게 내가 배운거야 간단하기 때문에 나는 항상 단수 사용했습니다. 최근에 새로운 스키마를 작성하는 동안 그러나, 오랜 시간에 처음으로, 나는 적극적으로 짧은 때문에 ... 단순히이 규칙을 유지하기로 결정했다. 모든 테이블 이름의 끝에 's'를 추가하면 모든 사람 앞에 'TBL_'를 추가하는 등 나에게 쓸모없는 것처럼 보인다.

28. ==============================

    28.난 항상 바보 같은 대회라고 생각. 나는 복수의 테이블 이름을 사용합니다.

    난 항상 바보 같은 대회라고 생각. 나는 복수의 테이블 이름을 사용합니다.

    (정책이 생산 개체 및 컬렉션 클래스에 ORM 코드 생성기에 대한보다 쉽게 ​​있다는 것을 그 반대의 경우도 마찬가지보다 단수 이름에서 복수의 이름을 생산하는 것이 더 쉽습니다 이후는 합리적인 뒤에 믿을 수)

29. ==============================

    29.난 단지, 같은 철자 단수 또는 복수 여부되어 내 테이블 이름에 대한 명사를 사용합니다 :

    난 단지, 같은 철자 단수 또는 복수 여부되어 내 테이블 이름에 대한 명사를 사용합니다 :

    엘크 물고기 사슴 항공기 당신 바지 반바지 안경 가위 종 자식

30. ==============================

    30.가이드 라인은 그냥 진짜로있다. 그것은 당신이 그들을 무시 할 수있는 옵션이 있습니다 이유 "돌에 새겨진"아니에요.

    가이드 라인은 그냥 진짜로있다. 그것은 당신이 그들을 무시 할 수있는 옵션이 있습니다 이유 "돌에 새겨진"아니에요.

    나는 그것이 복수로 테이블 이름을 가지고 논리적으로 직관적 것을 말할 것입니다. 테이블은 결국 기업의 모음입니다. 다른 대안 외에도 내가 일반적으로 테이블 이름에 접두사를 참조하십시오 언급 ...

    나는이 갈 방법을 알리는 아니에요 나는 또한 공간 내가 싫어 테이블 이름에 많이 사용을 참조하십시오. 바보 캐릭터가 좋아에 난 필드 이름에 걸쳐 왔어요? 처럼하면이 필드가 질문에 대한 대답 대답.

from https://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names by cc-by-sa and MIT license