테이블 명명 딜레마:단수 vs여러 이름

테이블 명명 딜레마:단수 vs여러 이름

닫았습니다. 이 질문은의견 기반의현재 답변을 받고 있지 않습니다.

---

이 질문을 개선하시겠습니까?이 게시물을 편집하여 사실과 인용문으로 답변할 수 있도록 질문을 업데이트하십시오.

9년 전에 문을 닫았어요

이 질문을 개선하다

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

둘, T-SQL의 했습니다.Users테이블을 사용하는 사람은 대괄호를 사용해야 하는 경우가 있습니다.

제 직감으로는 단수와 함께 있는 것이 더 맞다고 생각합니다만, 괄호는 공백이 들어간 칼럼명 등 바람직하지 않은 것을 나타내고 있는 것도 직감입니다.

내가 남아야 할까, 아니면 가야 할까?

저도 같은 질문이 있었습니다.여기서 모든 답을 읽고 SINGULER를 계속 사용하고 있습니다.이유는 다음과 같습니다.

이유 1(개념)."AppleBag"와 같은 사과가 든 가방을 떠올리면 사과가 0개든 100만개든 상관없습니다. 항상 같은 가방입니다.테이블은 컨테이너에 포함된 데이터의 양이 아니라 포함된 데이터를 설명하는 것입니다.또, 복수의 개념은, 구어(구어)에 관한 개념에 가깝다(실제로 1개 또는 복수의 개념이 있는지 아닌지를 판단한다).

이유 2. (편의성)여러 개의 이름을 붙이는 것보다 단수 이름을 붙이는 것이 더 쉽다.오브젝트는 불규칙한 복수형이거나 전혀 복수형이 아닐 수 있지만 (뉴스와 같은 예외는 거의 없음) 항상 단일형이 됩니다.

• 고객.
• 주문
• 사용자
• 상황
• 뉴스

이유 3. (감각과 질서)특히 마스터-상세 시나리오에서는 읽기 쉽고, 이름별로 정렬되며, 논리적인 순서(마스터 1위, 세부 2위)가 높아집니다.

• 1. 주문
• 2. 주문 상세

비교:

• 1. 주문 상세
• 2. 주문

이유 4(심플성).테이블 이름, 기본 키, 관계, 엔티티 클래스 모두 합쳐서...는, 2개의 이름(복수 클래스, 복수 테이블, 단수 필드, 단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단수-단

• Customer
• Customer.CustomerID
• CustomerAddress
• public Class Customer {...}
• SELECT FROM Customer WHERE CustomerID = 100

「고객」에의 대응이 확인되면, 모든 데이타베이스의 상호 작용의 요구에 대해서 같은 말을 사용할 수 있습니다.

이유 5. (글로벌화).세계는 점점 좁아지고 있습니다.여러분에게는 다른 국적의 팀이 있을 수 있습니다.모든 사람이 영어를 모국어로 사용하는 것은 아닙니다.비원어민 영어 프로그래머는 "Repository"보다 "Repository" 또는 "Status" 대신 "Status"를 생각하는 것이 더 쉬울 것입니다.이름을 단수화하면 오타를 줄일 수 있어 '자녀냐, 아이냐'라는 생각을 하지 않아도 되기 때문에 생산성이 향상된다.

이유 6 (왜?)쓰기 시간, 디스크 공간, 컴퓨터 키보드의 수명까지 단축할 수 있습니다.

• SELECT Customer.CustomerName FROM Customer WHERE Customer.CustomerID = 100
• SELECT Customers.CustomerName FROM Customers WHERE Customers.CustomerID = 103

3개의 문자, 3바이트, 3개의 추가 키보드 입력이 저장되었습니다. : )

그리고 마지막으로, 당신은 다음과 같은 예약명으로 엉망인 사람들의 이름을 지을 수 있습니다.

• User > Login User, App User, System User, CMS User, ...

또는 악명 높은 대괄호(사용자)를 사용합니다.

나는 영어에서는 단수인 무굴절 명사를 사용하는 것을 선호한다.

테이블 이름의 수를 굴절하면 맞춤법에 문제가 발생하지만(다른 많은 답변에서 알 수 있듯이), 일반적으로 테이블에는 여러 행이 포함되어 있기 때문에 이 방법을 선택하면 의미론적으로 구멍이 가득 차 있습니다.대소문자에 따라 명사를 변형하는 언어를 고려한다면(대부분이 그렇듯이) 이는 더욱 명백하다.

보통 줄타기 하는 거니까 고소장에 이름을 넣는 게 어때요?만약 우리가 읽은 것보다 더 많이 쓰는 표가 있다면, 왜 dative에 이름을 넣지 않는가?표가 하나 있는데 속격으로 하는 게 어때?테이블은 상태나 용도에 관계없이 존재하는 추상 컨테이너로 정의되기 때문에 이렇게 하지 않습니다.정확하고 절대적인 의미론적 이유 없이 명사를 굴절하는 것은 옹알이이다.

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

만약 당신이 객체 관계 매핑 도구를 사용하거나 앞으로 사용할 예정이라면, 나는 Singular를 추천한다.

LLBLGen과 같은 일부 도구는 테이블 이름 자체를 변경하지 않고 사용자 이름과 같은 여러 이름을 자동으로 수정할 수 있습니다.이게 왜 중요하죠?왜냐하면 매핑될 때 사용자처럼 보이고 싶기 때문입니다.사용자 이름 대신 이름.이전 데이터베이스 테이블에서 tblUsers.strName이라는 이름을 사용했는데 코드만 혼란스러울 뿐입니다.

나의 새로운 경험칙은 그것이 물체로 변환되면 어떻게 보일지 판단하는 것이다.

내가 사용하는 새 명명법에 맞지 않는 테이블 중 하나가 UsersInRoles입니다.단, 이러한 예외는 항상 존재하며, 이 경우에도 Users In Roles로 정상으로 보입니다.사용자 이름.

다른 사람들은 "기준"에 관한 한 꽤 좋은 대답을 해줬지만, 나는 단지 이 말을 덧붙이고 싶었다."사용자" (또는 "사용자")가 실제로 표에 저장된 데이터의 완전한 설명이 아닐 수 있습니까?테이블 이름이나 특정성에 너무 집착하는 것이 아니라 "Widget_Users"(여기서 "Widget"은 응용 프로그램 또는 웹 사이트 이름)가 더 적합합니다.

어떤 관례에 따라 테이블에 단수 이름을 붙여야 합니까?난 항상 복수 이름인 줄 알았어.

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

에서는 다음과 같은의견이 일치합니다.
http://vyaskn.tripod.com/object_naming.htm#Tableshttpvyaskn.tripod.com/.htm#Tables

사이트는 하지 않는다,
http://justinsomnia.org/writings/naming_conventions.htmlhttpjustinsomnia.org/writings/.html

---

다른 사람들이 언급했듯이, 이것들은 단지 지침일 뿐이다.귀하와 귀하의 회사/프로젝트에 적합한 규약을 선택하고 이를 준수하십시오.단수와 복수 사이를 바꾸거나 때로는 생략하고 때로는 생략하지 않는 것은 훨씬 더 악화된다.

예를 들어 다음과 같습니다.

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

대.

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

후자의 SQL은 전자의 SQL보다 이상하게 들린다.

나는 단수에게 투표한다.

나는 엔티티 관계도에서 엔티티가 단수인 것과 유사한 단수 이름으로 반영되어야 한다고 굳게 믿는다.인스턴스화되면 이름은 해당 인스턴스를 반영합니다.따라서 데이터베이스에서는 엔티티(엔티티 또는 레코드의 집합)를 테이블로 만들 때 엔티티가 복수입니다.엔티티, 사용자는 테이블 사용자로 생성됩니다.사용자라는 이름을 Employee로 개선하거나 귀사의 시나리오에 좀 더 적용할 수 있다고 제안한 다른 사용자들의 의견에 동의합니다.

그러면 레코드 그룹에서 선택하고 테이블 이름이 단수일 경우 제대로 읽을 수 없기 때문에 SQL 문에서 더 의미가 있습니다.

테이블 이름이나 프로그래밍 엔티티에 대해서는 단수를 사용합니다.

이유는?영어에는 쥐, 쥐, 양, 양처럼 불규칙한 복수가 있다는 사실.그리고 수집이 필요하면 마우스나 양만 쓰고 넘어갑니다.

그것은 정말 여러 사람이 눈에 띄는 데 도움이 되고, 나는 쉽고 계획적으로 물건의 모음을 결정할 수 있다.

그래서 제 규칙은 모든 것이 단수이고 모든 것의 집합은 단수이고 s가 붙습니다.ORM에도 도움이 됩니다.

IMHO, 테이블 이름은 Customers와 마찬가지로 복수여야 합니다.

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

단수형.나는 어느 것이 가장 논리적인지 어떤 주장도 믿지 않는다. 모든 사람은 자신의 선호가 가장 논리적이라고 생각한다.무엇을 하든 엉망진창이다. 규약을 하나 골라서 고수하라.매우 불규칙한 문법과 의미론(일반 구어 및 문자 언어)을 가진 언어를 매우 구체적인 의미론을 가진 매우 규칙적인(SQL) 문법에 매핑하려고 합니다.

나의 주된 주장은 테이블을 집합이 아니라 관계라고 생각한다는 것이다.

그...AppUser가 """인지 .AppUsers.

AppUserGroup가 어떤 엔티티인지 줍니다.AppUserGroups

AppUser_AppUserGroup란, 「어느 정도」가 되어 있는지를 나타냅니다.AppUsers ★★★★★★★★★★★★★★★★★」AppUserGroups련이있있 있있있다다

AppUserGroup_AppUserGroup가 말해 AppUserGroups ★★★★★★★★★★★★★★★★★」AppUserGroups관련이 있다(즉, 그룹의 그룹 멤버).

즉, 엔티티나 그 관련성을 생각할 때는 단수적으로 관계가 생각되지만, 물론 컬렉션이나 세트 내의 엔티티를 생각하면 컬렉션이나 세트가 복수입니다.

내 코드와 데이터베이스 스키마에서는 단수를 사용합니다.텍스트 기술에서는 가독성을 높이기 위해 복수형을 사용하고, 그 후 글꼴 등을 사용하여 표/관계명과 복수형을 구분합니다.

저는 그것을 지저분하지만 체계적이라고 생각하고 싶습니다.그리고 이렇게 하면 내가 표현하고 싶은 관계에 대해 체계적으로 생성된 이름이 항상 있습니다.이것은 나에게 매우 중요합니다.

저도 여러 가지 방법으로 하겠습니다.앞서 말한 사용자 딜레마에서는 각괄호 방식을 채택하고 있습니다.

코드 아티팩트의 사용자 컬렉션이 사용자 오브젝트의 컬렉션인 것처럼 사용자 테이블은 사용자 값의 컬렉션이라는 기본적인 이해를 바탕으로 데이터베이스 아키텍처와 애플리케이션 아키텍처 간의 통일성을 제공하기 위해 이 작업을 수행합니다.

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

개인적으로는 여러 이름을 사용하여 세트를 표현하는 것을 선호하지만, 내 관계형 마인드에는 "소리"가 더 낫습니다.

바로 지금, 저는 회사의 데이터 모델을 정의하기 위해 단수 이름을 사용하고 있습니다. 왜냐하면 직장인 대부분이 데이터 모델에 대해 더 쾌적하게 느끼기 때문입니다.때때로 당신은 개인적인 취향을 강요하는 대신 모든 사람들에게 삶을 더 편하게 만들어야 한다.(테이블 이름 붙이기 베스트 프랙티스가 무엇인지 확인하기 위해 이 스레드에 들어가게 되었습니다)

이 글을 읽고 나는 한 가지 결론에 도달했다.

나는 꿀이 들어간 팬케이크를 좋아한다. 모두가 좋아하는 맛이 무엇이든.하지만 만약 내가 다른 사람들을 위해 요리를 한다면, 나는 그들이 좋아하는 것을 대접하려고 노력할 것이다.

저는 사실 테이블 네임을 여러 개 사용하는 것이 일반적인 관례라고 생각해 왔습니다.지금까지 나는 항상 복수형을 사용해 왔다.

단수 테이블 이름에 대한 주장은 이해할 수 있지만, 나에게는 복수형이 더 말이 된다.일반적으로 테이블 이름은 테이블에 포함된 내용을 나타냅니다.정규화된 데이터베이스에서는 각 테이블에는 특정 데이터 세트가 포함됩니다.각 행은 엔티티이며 테이블에는 많은 엔티티가 포함됩니다.따라서 테이블 이름의 복수 형식입니다.

자동차 테이블에는 자동차라는 이름이 있고 각 열은 자동차입니다.테이블과 필드를 함께 지정하는 것은 인정합니다.table.field매너는 베스트 프랙티스이며 단수 테이블 이름을 가지는 것이 더 읽기 쉽다는 것입니다.단, 다음 두 가지 예에서는 전자가 더 타당합니다.

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

솔직히 말해서, 저는 이 문제에 대한 제 입장을 재고하고, 제가 개발하고 있는 조직이 실제로 사용하는 규약에 의존할 것입니다.다만, 제 개인적인 관례상, 저는 여러 개의 테이블 이름을 고수할 것이라고 생각합니다.내게는 그게 더 말이 된다.

단수형.다수의 사용자 행 표현 개체를 포함하는 어레이를 "users"라고 부르지만 테이블은 "user table"테이블이 포함된 행의 집합일 뿐이라고 생각하는 것은 잘못된 것입니다.IMO. 테이블은 메타데이터이며 행의 집합은 테이블에 계층적으로 연결되어 있지 않습니다.

물론 항상 ORM을 사용하고 있기 때문에 테이블명이 여러 개 적혀 있는 ORM 코드가 우습게 보일 수 있습니다.

나는 여러 개의 테이블 이름을 좋아하지 않는다. 왜냐하면 영어의 명사 중에는 셀 수 없는 것(물, 수프, 현금)이나 셀 수 있는 것(닭 대 닭, 고기 대 새)에 따라 의미가 바뀌기 때문이다.또한 테이블 이름이나 열 이름에 약어를 사용하는 것도 싫어합니다. 약어를 사용하면 이미 가파른 학습 곡선에 기울기가 추가되기 때문입니다.

아이러니컬하게도, 제가User라고 것UsersUSER(Transac-SQL) 때문에, 저도 굳이 테이블 주위에 대괄호를 사용하는 것을 좋아하지 않기 때문입니다.

칸을 아이디로 을 좋아합니다.Id 아니라, 이에요.ChickenId ★★★★★★★★★★★★★★★★★」ChickensId(이것들)

이 모든 것은 데이터베이스 시스템에 대한 존경심이 없기 때문에, 저는 단지 Java의 습관이나 게으름과 같은 OO 명명 규칙의 원트릭 포니 지식을 다시 적용하고 있을 뿐입니다.복잡한 SQL에 대한 IDE 지원이 더 있었으면 좋겠어요.

스크립트 작성 시 [ ]에 이름을 붙여야 하며, 스키마 한정자가 적절한 경우 주로 SQL 구문에 의한 향후 이름 취득에 대한 내기를 회피합니다.

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

이것은 과거 우리의 영혼을 구했습니다.데이터베이스 시스템 중 일부는 SQL 6.0에서 SQL 2005까지 10년 이상 가동되었습니다.이는 의도한 수명을 훨씬 초과한 것입니다.

★★을 보면MS SQL Server's 테이블,, Microsoft에 의해 할당된 plural.

Oracle의은 Oracle에 .singular아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 네.Oracle은 사용자 정의 테이블 이름에는 여러 개를 사용할 것을 권장합니다.그들이 한 가지를 추천하고 다른 것을 따르는 것은 말이 안 된다.이 두 소프트웨어 대기업의 설계자들이 서로 다른 관례를 사용하여 테이블에 이름을 붙였다는 것도 말이 안 됩니다.★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★? 박사

학계에서는 추천이 특이했던 것으로 기억합니다.

예를 들어 다음과 같이 말합니다.

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

B 수 있습니다.ID정정? ?? ???...?

표: 복수

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

모델: 단수

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

컨트롤러: 복수

http://myapp.com/users 에는 여러 사용자가 표시됩니다.

어쨌든 그건 내 생각이다.

시tables/views의 (서버 자체SYSCAT.TABLES,dbo.sysindexes,ALL_TABLES,information_schema.columns는 거의 일관성을 위해서라도 그들의 선례를 따를 것 같아요.

CASE 구문을 사용한 ER 도표를 읽기 쉽게 하기 때문에 단수 테이블명의 팬입니다만, 이 응답을 읽으면 전혀 인기가 없는 것 같은 느낌이 듭니다.개인적으로 너무 좋아요.단수 테이블 이름을 사용하고, 관계에 액션 동사를 추가하고, 모든 관계에 대해 좋은 문장을 형성할 때 모델이 얼마나 읽을 수 있는지에 대한 좋은 개요가 있습니다.20개의 테이블 데이터베이스치고는 다소 무리이지만, 수백 개의 테이블과 복잡한 설계가 있는 DB를 가지고 있다면, 제대로 읽을 수 있는 도표가 없으면 개발자가 어떻게 이해할 수 있을까요?

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

표와 뷰에 접두사를 붙이는 것에 대해 나는 그 관행이 정말 싫다.사람들에게 나쁜 정보를 주기 전에 정보를 전혀 주지 마세요.오브젝트용 DB를 참조하는 사람은 보기만 봐도 쉽게 알 수 있지만, tblUsers라는 이름의 테이블이 있기 때문에 나중에 두 개의 테이블로 재구축하고 오래된 코드가 깨지지 않도록 통합하기로 결정했습니다.이 시점에서는 매력적이지 않은2가지 옵션이 남습니다.tbl 프리픽스가 붙은 뷰는 일부 개발자를 혼란스럽게 하거나 다른 레이어(중간층 또는 애플리케이션)를 새로운 구조 또는 이름 viewUsers를 참조하도록 다시 작성하도록 강요할 수 있습니다.그것은 IMHO 뷰의 가치의 큰 부분을 부정한다.

사용자 테이블에서 "Dude"를 사용한 적이 있습니다.단문자는 같고 키워드와 경합하지 않으며 일반인을 지칭합니다.암호를 볼 수 있는 답답한 머리가 걱정되지 않았다면 그렇게 했을 거예요.

난 항상 단수를 사용해왔어 그렇게 배웠기 때문이지하지만 최근 새로운 스키마를 만들면서 오랜만에 적극적으로 이 규약을 유지하기로 결심하게 된 이유는...더 짧아요.모든 테이블 이름 끝에 's'를 추가하는 것은 모든 테이블 이름 앞에 'tbl_'를 추가하는 것만큼 쓸모없는 것처럼 보입니다.

이것은 다소 중복될 수 있지만, 조심할 것을 권합니다.테이블의 이름을 바꾸는 것이 반드시 나쁜 것은 아니지만, 표준화는 단지 표준일 뿐입니다.표준--이 데이터베이스는 이미 「표준화」되어 있을 수 있습니다.이 데이터베이스는 이미 존재하고, 아마 2개 이상의 테이블로 구성되어 있기 때문에, 일관성이 더 좋은 목표가 될 것을 제안합니다.

데이터베이스 전체를 표준화할 수 없거나 적어도 그 목적을 위해 작업할 계획이 없는 한 테이블 이름은 빙산의 일각에 불과하며 이름 없는 객체의 고통을 견디면서 당면한 작업에 집중하는 것이 가장 유리할 수 있습니다.

실제적인 일관성이 최고의 기준이 될 수 있습니다.:)

my2cp ---

여기서 언급한 바와 같이 표기법은 사용 편의성과 가독성을 높이기 위한 도구가 되어야 합니다.개발자들을 고문하는 족쇄나 곤봉이 아닙니다.

단, 저는 테이블과 컬럼 모두에 단수 이름을 사용하는 것을 개인적으로 선호합니다.이것은 아마도 나의 프로그래밍 배경에서 나온 것 같다.클래스 이름은 집합이 아닌 한 일반적으로 단수입니다.내 생각에는 나는 문제의 표에 개별 기록을 저장하거나 읽고 있기 때문에 단수라고 하는 것은 이해가 된다.

이 연습에서는 오브젝트 간의 다대다 관계를 저장하는 테이블 이름을 여러 개 예약할 수도 있습니다.

테이블이나 컬럼 이름에도 예약어는 사용하지 않도록 합니다.여기서의 경우는, 유저의 예약어를 사용하는 테이블을 캡슐화할 필요가 없게 하기 위해서, 유저 전용의 규칙에 반하는 것이 보다 타당합니다.

많은 사람들은 이것이 혼란을 가중시킨다고 생각하지만, 나는 제한된 방식으로 접두사를 사용하는 것을 좋아합니다(테이블 이름에는 tbl, proc 이름에는 sp_ 등).또한 이름을 입력할 때는 항상 _ 대신 +를 누르기 때문에 밑줄보다는 CamelBack 이름을 선호합니다.다른 많은 사람들은 동의하지 않는다.

명명규칙 가이드라인에 대한 또 다른 링크를 소개합니다.http://www.xaprb.com/blog/2008/10/26/the-power-of-a-good-sql-naming-convention/

컨벤션에서 가장 중요한 요소는 해당 데이터베이스와 상호 작용하는 사용자에게 의미가 있다는 점에 유의하십시오.명명 규칙에 관한 한 "One Ring to Rule Them All"은 없습니다.

가능한 대체 방법:

• 테이블의 이름을 System User로 변경합니다.
• 괄호 사용
• 여러 테이블 이름을 유지합니다.

괄호를 사용하는 IMO는 기술적으로 좀 번거롭지만 가장 안전한 방법입니다.IMO는 하나 중 여섯 개, 다른 하나는 여섯 개입니다.솔루션의 요점은 개인/팀 선호입니다.

컨테이너를 어떻게 정의하느냐에 따라 의미가 달라집니다.예를 들어, "사과 봉지" 또는 "사과 봉지" 또는 "사과"가 있습니다.

예: "college" 테이블에는 0개 이상의 대학을 포함할 수 있습니다. "colleges" 테이블에는 0개 이상의 대학을 포함할 수 있습니다.

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

결론은 어느 쪽이든 괜찮지만 테이블을 참조할 때 자신(또는 테이블과 상호작용하는 사람)이 어떻게 접근할지 정의해야 합니다('x 테이블' 또는 'xs 테이블').

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

나는 영어의 여러 가지 불규칙성 때문에 지금 나는 단수에게 유리하게 팁을 주고 있다고 생각한다.독일어에서는 일관된 복수형이 없기 때문에 더욱 심각합니다.때로는 단어 앞에 명기된 기사(der/die/das)가 없으면 단어가 복수인지 아닌지를 구분할 수 없습니다.그리고 중국어에는 어차피 복수형이 없어요.

나는 항상 그것이 멍청한 관습이라고 생각했다.저는 여러 개의 테이블 이름을 사용합니다.

(오브젝트나 컬렉션 클래스의 작성은 ORM 코드 생성자가 그 반대보다 하나의 이름으로부터 복수의 이름을 작성하기 쉽기 때문에, 그 정책의 이면에 있는 것이 합리적이라고 생각합니다.)

단수든 복수든 같은 이름의 테이블 이름에만 명사를 사용합니다.

무스 어류 사슴 항공기 your pants 반바지 안경 가위종 자손

나는 이전 답변들 중 어느 것에서도 이것이 명확하게 표현되는 것을 보지 못했다.많은 프로그래머들이 표를 사용할 때 공식적인 정의를 염두에 두지 않습니다.우리는 종종 "기록"이나 "행"의 관점에서 직관적으로 의사소통을 합니다.단, 정규화되지 않은 관계에 대한 몇 가지 예외를 제외하고 테이블은 보통 비키 속성과 키 사이의 관계가 설정된 이론 함수를 구성하도록 설계됩니다.

함수는 두 세트 간의 교차 곱의 서브셋으로 정의할 수 있으며, 여기서 키 세트의 각 요소는 매핑에서 최대 한 번 발생합니다.따라서 그러한 관점에서 생겨난 용어는 단일한 경향이 있다.함수(예: 대수학 및 람다 미적분학)와 관련된 다른 수학 및 계산 이론에서 동일한 단수(또는 적어도 비복수) 관례를 볼 수 있다.

언급URL : https://stackoverflow.com/questions/338156/table-naming-dilemma-singular-vs-plural-names