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


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

Question

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

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

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

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




Possible alternatives:

  • Rename the table SystemUser
  • Use brackets
  • Keep the plural table names.

IMO using brackets is technically the safest approach, though it is a bit cumbersome. IMO it's 6 of one, half-a-dozen of the other, and your solution really just boils down to personal/team preference.




I am a fan of singular table names as they make my ER diagrams using CASE syntax easier to read, but by reading these responses I'm getting the feeling it never caught on very well? I personally love it. There is a good overview with examples of how readable your models can be when you use singular table names, add action verbs to your relationships and form good sentences for every relationships. It's all a bit of overkill for a 20 table database but if you have a DB with hundreds of tables and a complex design how will your developers ever understand it without a good readable diagram?

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

As for prefixing tables and views I absolutely hate that practice. Give a person no information at all before giving them possibly bad information. Anyone browsing a db for objects can quite easily tell a table from a view, but if I have a table named tblUsers that for some reason I decide to restructure in the future into two tables, with a view unifying them to keep from breaking old code I now have a view named tblUsers. At this point I am left with two unappealing options, leave a view named with a tbl prefix which may confuse some developers, or force another layer, either middle tier or application to be rewritten to reference my new structure or name viewUsers. That negates a large part of the value of views IMHO.




IMHO, table names should be plural like Customers .

Class names should be singular like Customer if it maps to a row in the Customers table.




We run similar standards, when scripting we demand [ ] around names, and where appropriate schema qualifiers - primarily it hedges your bets against future name grabs by the SQL syntax.

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

This has saved our souls in the past - some of our database systems have run 10+ years from SQL 6.0 through SQL 2005 - way past their intended lifespans.




This may be a bit redundant, but I would suggest being cautious. Not necessarily that it's a bad thing to rename tables, but standardization is just that; a standard -- this database may already be "standardized", however badly :) -- I would suggest consistency to be a better goal given that this database already exists and presumably it consists of more than just 2 tables.

Unless you can standardize the entire database, or at least are planning to work towards that end, I suspect that table names are just the tip of the iceberg and concentrating on the task at hand, enduring the pain of poorly named objects, may be in your best interest --

Practical consistency sometimes is the best standard... :)

my2cents ---




My take is in semantics depending on how you define your container. For example, A "bag of apples" or simply "apples" or an "apple bag" or "apple".

Example: a "college" table can contain 0 or more colleges a table of "colleges" can contain 0 or more collegues

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

My conclusion is that either is fine but you have to define how you (or people interacting with it) are going to approach when referring to the tables; "ax table" or a "table of xs"




테이블에서 단수 이름을 사용해야하는 규칙은 무엇입니까? 나는 항상 그것이 복수 이름이라고 생각했다.

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

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

이 사이트는 동의하지 않습니다 (그러나 동의하지 않습니다).
http://justinsomnia.org/writings/naming_conventions.html

다른 사람들이 언급했듯이 : 이것은 단지 지침 일뿐입니다. 귀하와 귀하의 회사 / 프로젝트에 적합한 컨벤션을 선택하고 준수하십시오. 단수와 복수 또는 때때로 약어를 바꾸거나 때로는 그렇지 않은 경우가 훨씬 더 심합니다.




미래에는 Object Relational Mapping 도구 또는 의지를 사용하는 경우 Singular를 제안합니다.

LLBLGen과 같은 일부 도구는 테이블 이름 자체를 변경하지 않고 사용자와 같은 복수 이름을 자동으로 수정할 수 있습니다. 왜이 문제가 중요합니까? 매핑이되면 Users.Name 대신 User.Name처럼 보이거나 코드에서 혼란스러운 tblUsers.strName이라는 이름의 기존 데이터베이스 테이블에서 더 악화되기를 원하기 때문입니다.

새로운 경험 법칙은 일단 객체로 변환되면 어떻게 보이는지 판단하는 것입니다.

내가 사용한 새로운 이름 지정에 맞지 않는 테이블 하나가 UsersInRoles입니다. 하지만 항상 예외는 거의 없으며이 경우에도 UsersInRoles.Username처럼 잘 보입니다.




If we look at MS SQL Server's system tables, their names as assigned by Microsoft are in plural .

The Oracle's system tables are named in singular . Although a few of them are plural. Oracle recommends plural for user-defined table names. That doesn't make much sense that they recommend one thing and follow another. That the architects at these two software giants have named their tables using different conventions, doesn't make much sense either... After all, what are these guys ... PhD's?

I do remember in academia, the recommendation was singular.

For example, when we say:

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

maybe b/c each ID is selected from a particular single row ...?




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

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

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

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

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

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

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

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

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




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

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




I once used "Dude" for the User table - same short number of characters, no conflict with keywords, still a reference to a generic human. If I weren't concerned about the stuffy heads that might see the code, I would have kept it that way.




I always thought that was a dumb convention. I use plural table names.

(I believe the rational behind that policy is that it make it easier for ORM code generators to produce object & collection classes, since it is easier to produce a plural name from a singular name than vice-versa)




나는 Entity Relation Diagram에서 개체가 하나의 클래스 이름과 비슷한 하나의 이름으로 반영되어야한다는 확고한 신념을 가지고 있습니다. 일단 인스턴스화되면 이름은 인스턴스를 반영합니다. 따라서 데이터베이스의 경우 엔티티는 테이블 (엔티티 또는 레코드의 모음)로 구성 될 때 복수형입니다. 엔티티, 사용자는 테이블 사용자로 만들어집니다. 나는 아마도 사용자가 Employee로 개선 할 수있는 이름을 제안하거나 시나리오에보다 적합한 것을 제안한 다른 사람들과 동의 할 것이다.

이렇게하면 레코드 그룹에서 선택하고 테이블 이름이 단수이면 잘 읽지 않으므로 SQL 문에서 더 적합합니다.




Related