테이블 이름 딜레마 : 단수와 복수 이름 [닫기]

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

나는 이름 주위에 대괄호가 필요한 T-SQL을 싫어하지만 Users테이블의 이름 을 단수로 바 꾸었습니다 .

내 직감은 단수를 유지하는 것이 더 정확하다는 것입니다. 그러나 내 직감은 괄호 안에 공백이있는 열 이름과 같은 바람직하지 않은 항목을 나타냅니다.

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

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

나는 같은 질문을했고, 여기에있는 모든 답변을 읽은 후에는 분명히 SINGULAR에 머물러 있습니다.

이유 1 (개념). "AppleBag"와 같은 사과가 들어있는 주머니를 생각할 수 있습니다. 0, 1 개 또는 백만 개의 사과가 들어 있는지 여부는 중요하지 않으며 항상 같은 주머니입니다. 테이블은 컨테이너입니다. 테이블 이름은 테이블에 포함 된 데이터의 양이 아니라 포함 된 내용을 설명해야합니다. 또한, 복수 개념은 구어 언어에 관한 것입니다 (실제로 하나 이상이 있는지 여부를 결정하기 위해).

이유 2 . (편의). 복수 이름보다 단수 이름으로 나오는 것이 더 쉽습니다. 객체는 불규칙 복수형 또는 복수형이 아닐 수 있지만 항상 단수형을 갖습니다 (뉴스와 같은 예외는 거의 없음).

• 고객
• 주문
• 사용자
• 상태
• 뉴스

이유 3 . (미학과 질서). 특히 마스터-디테일 시나리오에서 이것은 더 잘 읽히고 이름별로 더 잘 정렬되며 더 논리적 인 순서를 갖습니다 (Master first, Detail second) :

• 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]를 사용하십시오

객체 관계형 매핑 도구를 사용하거나 향후에 Singular를 제안 합니다.

LLBLGen과 같은 일부 도구는 테이블 이름 자체를 변경하지 않고 Users to User와 같은 복수 이름을 자동으로 수정할 수 있습니다. 이것이 왜 중요한가? 매핑 할 때 코드에서 혼란스러워하는 tblUsers.strName이라는 이름의 오래된 데이터베이스 테이블에서 Users.Name 대신 User.Name 또는 User.Name처럼 보이기를 원하기 때문입니다.

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

내가 찾은 새로운 이름에 맞지 않는 한 테이블은 UsersInRoles입니다. 그러나 항상 몇 가지 예외가 있으며이 경우에도 UsersInRoles.Username처럼 보입니다.

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

테이블 이름의 수를 반영하면 다른 많은 답변이 보여주는 것처럼 직교 문제가 발생하지만 일반적으로 테이블에 여러 행이 포함되어 있기 때문에 선택적으로 구멍이 가득합니다. 대소 문자에 따라 명사를 구사하는 언어를 고려하면 더 분명합니다.

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

무의미한 명사를 사용하는 것은 간단하고 논리적이며 규칙적이며 언어에 독립적입니다.

테이블에 단수 이름이 필요한 규칙은 무엇입니까? 나는 항상 그것이 복수의 이름이라고 생각했다.

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

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

이 사이트는 동의하지 않지만 동의하지는 않습니다 :
http://justinsomnia.org/writings/naming_conventions.html

다른 사람들이 언급했듯이 이것은 지침 일뿐입니다. 당신과 당신의 회사 / 프로젝트에 맞는 협약을 고르십시오. 단수형 또는 복수형 또는 간결한 단어 간을 전환하고 때로는 더 심하지 않은 경우가 있습니다.

간단한 예로써 어떻습니까?

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

vs.

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

후자의 SQL은 전자보다 낯설다.

나는 단수 투표 .

엔터티 관계 다이어그램에서 엔터티는 클래스 이름과 비슷한 단일 이름으로 반영되어야한다고 확신합니다. 인스턴스화되면 이름에 해당 인스턴스가 반영됩니다. 따라서 데이터베이스를 사용하면 테이블 (엔티티 또는 레코드 모음)으로 만들 때 엔터티가 여러 개가됩니다. 엔터티, 사용자는 테이블 사용자로 만들어집니다. 사용자 이름을 직원으로 향상시킬 수 있거나 귀하의 시나리오에 더 적합한 것을 제안한 다른 사람들에게 동의합니다.

레코드 그룹에서 선택하고 테이블 이름이 단수이면 잘 읽지 않기 때문에 SQL 문에서 더 의미가 있습니다.

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

이유? 같은 영어 불규칙 복수형이 있다는 사실 마우스 ⇒ 마우스 와 양 ⇒ 양 . 그런 다음 컬렉션이 필요하면 마우스 또는 양을 사용 하고 계속 진행하십시오.

그것은 실제로 다수가 눈에 띄는 데 도움이되며, 물건 모음이 어떻게 보일지 쉽고 프로그래밍 방식으로 결정할 수 있습니다.

그래서, 내 규칙이 있습니다 : 모든 단수, 사물의 모든 컬렉션은과 단수 의 추가. ORM에도 도움이됩니다.

IMHO, 테이블 이름은 Customers 와 같이 복수 여야합니다 .

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

단수형. 나는 가장 논리적 인 논쟁을 사지 않는다-모든 사람들은 자신의 선호가 가장 논리적이라고 생각한다. 당신이 무엇을 하든지 엉망이 될 수 있습니다. 컨벤션을 선택하고 고수하십시오. 우리는 매우 불규칙적 인 문법과 의미론 (정상 음성 및 작문 언어)을 가진 언어를 매우 특정한 의미론을 가진 고도의 정규 (SQL) 문법으로 매핑하려고합니다.

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

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

AppUserGroup관계는 실체가있는 저에게 말한다AppUserGroups

AppUser_AppUserGroup관계는 어떻게 나에게 말한다 AppUsers와 AppUserGroups관련이 있습니다.

AppUserGroup_AppUserGroup관계는 어떻게 나에게 말한다 AppUserGroups및 AppUserGroups(그룹 즉 그룹의 멤버)와 관련이 있습니다.

다시 말해서, 엔티티에 대해 생각할 때 그리고 관계가 어떻게 연관되어 있는지를 단수로 생각합니다. 물론 컬렉션이나 세트에있는 엔티티를 생각할 때 컬렉션이나 세트는 복수입니다.

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

나는 그것을 지저분하지만 체계적이라고 생각하고 싶습니다.이 방법은 항상 표현하고자하는 관계에 대해 체계적으로 생성 된 이름이 있습니다.

또한 복수형 을 사용하고 앞에서 언급 한 사용자 딜레마 와 함께 대괄호 방식을 사용합니다.

코드 아티팩트 의 Users 컬렉션이 User 개체 의 컬렉션 인 것처럼 Users 테이블이 User 값 의 컬렉션 이라는 기본 이해를 통해 데이터베이스 아키텍처와 응용 프로그램 아키텍처간에 균일 성을 제공 합니다.

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

나는 개인적으로 집합을 표현하기 위해 복수의 이름을 사용하는 것을 선호하는데, 그것은 단지 내 관계형 마음에 더 잘 들린다.

이 정확한 순간에 나는 회사의 데이터 모델을 정의하기 위해 단수의 이름을 사용하고 있습니다. 왜냐하면 대부분의 직장인들이 더 편하게 느끼기 때문입니다. 때때로 당신은 당신의 개인적인 취향을 강요하는 대신 모든 사람에게 인생을 더 편하게 만들어야합니다. (그래서 테이블 이름 지정을위한 "모범 사례"가 무엇인지 확인하기 위해이 스레드에서 결과를 얻었습니다)

이 스레드에서 모든 논쟁을 읽은 후 한 가지 결론에 도달했습니다.

나는 모든 사람이 좋아하는 맛이 무엇이든 꿀로 팬케이크를 좋아합니다. 하지만 다른 사람들을 위해 요리를한다면 그들에게 그들이 좋아하는 것을 제공하려고 노력할 것입니다.

단수형. 많은 사용자 행 표현 객체 'users'를 포함하는 배열을 호출하지만 테이블은 'user table'입니다. 테이블에 포함 된 행 집합 외에 다른 것으로 생각하는 것은 잘못입니다 (IMO). 테이블은 메타 데이터이며 행 집합은 테이블에 계층 적으로 연결되며 테이블 자체는 아닙니다.

물론 ORM을 항상 사용하며 복수 테이블 이름으로 작성된 ORM 코드가 어리석게 보이도록 도와줍니다.

나는 실제로 항상 복수 테이블 이름을 사용하는 것이 보편적 인 관례라고 생각했습니다. 이 시점까지는 항상 복수형을 사용했습니다.

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

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

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

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

영어로 된 일부 명사는 셀 수 없거나 (물, 수프, 현금) 셀 수 없을 때 의미가 변하기 때문에 (치킨 vs 닭; 고기 vs 조류) 표 이름이 마음에 들지 않습니다. 또한 테이블 이름 또는 열 이름에 약어를 사용하는 것을 싫어합니다. 그렇게하면 이미 가파른 학습 곡선에 경사가 더 커지기 때문입니다.

아이러니하게도, USER (Transac-SQL) 때문에 User예외를 만들고 호출 할 수 있습니다. 필요하지 않은 경우 테이블 주위에 대괄호를 사용하는 것을 좋아하지 않기 때문입니다.Users

또한 모든 ID 열의 이름을로 지정 하거나으로 지정 Id하지 않고 있습니다 (여러 사람이 어떻게해야합니까?)ChickenIdChickensId

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

우리는 스크립팅 할 때 이름 주위에 []가 필요하고 적절한 스키마 한정자가 필요한 경우 비슷한 표준을 실행합니다. 주로 SQL 구문에 의해 향후 이름 잡기에 대비하여 베팅을 방지합니다.

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

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

테이블 : 복수

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

모델 : 단수

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

컨트롤러 : 복수

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

어쨌든 그것은 내 취향입니다.

CASE 구문을 사용하여 ER 다이어그램을 읽기 쉽도록 단일 테이블 이름을 좋아하는 팬이지만 이러한 응답을 읽음으로써 전혀 잘 이해하지 못하는 느낌이 들까 요? 나는 개인적으로 그것을 사랑합니다. 단일 테이블 이름을 사용하고 관계에 동작 동사를 추가하고 모든 관계에 대해 좋은 문장을 만들 때 모델을 읽을 수있는 방법에 대한 예제가 좋은 개요입니다. 20 개의 테이블 데이터베이스에는 다소 과잉이지만 수백 개의 테이블이있는 DB와 복잡한 디자인이 있다면 개발자가 읽을 수있는 다이어그램이 없으면 데이터베이스를 어떻게 이해할 수 있습니까?

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

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

시스템 tables/views서버 자체의가 ( SYSCAT.TABLES, dbo.sysindexes, ALL_TABLES, information_schema.columns, 등) 거의 항상 복수입니다. 일관성을 유지하기 위해 그들의 리드를 따를 것이라고 생각합니다.

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

Oracle의 시스템 테이블 이름은에 singular있습니다. 그들 중 일부는 복수형이지만. Oracle은 사용자 정의 테이블 이름에 복수를 권장합니다. 그들이 한 가지를 추천하고 다른 것을 따르는 것은 그리 의미가 없습니다. 이 두 소프트웨어 거인의 건축가가 다른 규칙을 사용하여 테이블의 이름을 지정했다는 것은 큰 의미가 없습니다 ... 결국,이 사람들은 무엇입니까 ... 박사?

나는 학계에서 기억이 좋습니다, 추천은 단수였습니다.

예를 들어, 다음과 같이 말할 때 :

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

아마도 b / c 각각 ID은 특정 단일 행에서 선택됩니다 ...?

이것은 약간 중복 될 수 있지만 조심스럽게 제안 할 것입니다. 반드시 테이블 이름을 바꾸는 것이 나쁜 것은 아니지만 표준화는 바로 그 것입니다. 표준-이 데이터베이스는 이미 "표준화되었지만"나쁘게 :)-이 데이터베이스가 이미 존재하고 아마도 2 개 이상의 테이블로 구성되어 있다고 가정하면 일관성을보다 나은 목표로 제안합니다.

전체 데이터베이스를 표준화하거나 최소한 그 목표를 향해 노력할 계획이 아니라면 테이블 이름은 빙산의 일각에 불과하고 당면한 작업에 집중하여 이름이 잘못 지정된 개체의 고통을 견뎌 낼 수 있습니다. 당신의 최선의 관심-

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

my2cents ---

가능한 대안 :

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

대괄호를 사용하는 IMO는 기술적으로 가장 안전한 방법이지만 약간 성가시다. IMO는 6 개 중 6 개이며 다른 하나는 6 개이며 솔루션은 실제로 개인 / 팀 기본 설정으로 요약됩니다.

컨테이너를 정의하는 방법에 따라 의미가 중요합니다. 예를 들어 "사과 봉지"또는 단순히 "사과"또는 "사과 봉지"또는 "사과"입니다.

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

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

내 결론은 어느 쪽이든 괜찮지 만 테이블을 참조 할 때 자신 (또는 그와 상호 작용하는 사람들)이 어떻게 접근 할 것인지 정의해야한다는 것이다. "ax 테이블"또는 "xs 테이블"

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

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

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

테이블 및 열 이름에서 예약어도 피하려고합니다. 여기서 문제가되는 경우, 예약 된 User라는 단어를 사용하는 테이블을 캡슐화 할 필요가 없도록하기 위해 사용자가 단일 규칙에 반하는 것이 더 합리적입니다.

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

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

컨벤션에서 가장 중요한 요소는 문제의 데이터베이스와 상호 작용하는 사람들에게 의미가 있다는 것입니다. 명명 규칙과 관련하여 "모든 것을 지배하는 하나의 고리"는 없습니다.

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

나는 영어의 복수의 불규칙성으로 인해 현재 단수를 선호한다고 생각합니다. 독일어에서는 일관된 복수형이 없기 때문에 훨씬 더 나쁩니다. 때로는 단어 앞에 단어를 지정하지 않으면 단어가 복수인지 아닌지를 알 수 없습니다 (der / die / das). 그리고 중국어로는 어쨌든 복수형이 없습니다.

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

나는 그것이 제가 가르치는 것이기 때문에 항상 단수형을 사용했습니다. 그러나 최근에 처음으로 새로운 스키마를 만들면서 오랫동안이 규칙을 유지하기로 결정했습니다. 모든 테이블 이름 끝에 's'를 추가하면 모든 테이블 앞에 'tbl_'을 추가하는 것처럼 나에게는 쓸모없는 것처럼 보입니다.

나는 항상 그것이 멍청한 협약이라고 생각했다. 복수 테이블 이름을 사용합니다.

(이 정책의 합리적 근거는 ORM 코드 생성기가 객체 및 컬렉션 클래스를 생성하는 것이 더 쉽다는 것입니다. 그 반대의 경우보다 단일 이름에서 복수 이름을 생성하는 것이 더 쉽기 때문입니다)

단수형이든 복수형이든, 철자가 동일한 테이블 이름에는 명사 만 사용합니다.

무스 물고기 사슴 항공기 당신 바지 반바지 안경 가위 종 자손

나는 이것이 이전 답변 중 어느 것에서도 명확하게 표현 된 것을 보지 못했습니다. 많은 프로그래머는 테이블 작업시 공식적인 정의를 염두에 두지 않습니다. 우리는 종종 "레코드"또는 "행"의 관점에서 직관적으로 의사 소통합니다. 그러나 비정규 화 된 관계에 대한 일부 예외를 제외하고 테이블은 일반적으로 키가 아닌 속성과 키 사이의 관계가 이론 이론 함수를 구성하도록 설계됩니다.

함수는 두 세트 사이의 교차 곱의 서브 세트로 정의 될 수 있으며, 키 세트의 각 요소 는 맵핑 에서 최대 한 번 발생합니다 . 그러므로 그러한 관점에서 비롯된 용어는 단수 인 경향이 있습니다. 함수 (예를 들어 대수와 람다 미적분학)를 포함하는 다른 수학적 및 계산 이론에서 동일한 단수 (또는 적어도 비 복수)의 관례를 봅니다.