No error , No gain

Question 1

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

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

내 직감은 단수로 유지하는 것이 더 정확하지만 대괄호는 공백이 있는 열 이름과 같은 바람직하지 않은 것을 나타내는 것입니다.

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

Question 2

나는 같은 질문을했고 여기에서 모든 답변을 읽은 후에 나는 분명히 SINGULAR에 머물렀습니다. 이유는 다음과 같습니다.

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

이유 2 . (편의). 복수 이름보다 단수 이름이 더 쉽습니다. 객체는 불규칙한 복수형을 가질 수도 있고 복수형이 아닐 수도 있지만 항상 단수형을 갖습니다(뉴스와 같은 몇 가지 예외는 제외).

고객
주문하다
사용자
상태
소식

이유 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,...

또는 악명 높은 대괄호를 사용하십시오. [사용자]

Question 3

Object Relational Mapping 도구를 사용하거나 앞으로 사용할 예정이라면 Singular를 제안합니다.

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

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

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

Question 4

다른 사람들은 "표준"에 관한 한 꽤 좋은 답변을 제공했지만 나는 이것을 추가하고 싶었습니다 ... "사용자"(또는 "사용자")가 실제로 테이블에 보관된 데이터의 전체 설명이 아닐 수 있습니까? ? 테이블 이름과 특정성에 너무 집착해서는 안 되지만 "Widget_Users"(여기서 "Widget"은 애플리케이션 또는 웹사이트의 이름)와 같은 것이 더 적절할 것입니다.

Question 5

나는 영어에서 우연히 단수인 굴절되지 않은 명사를 사용하는 것을 선호합니다.

테이블 이름의 수를 변경하면 철자법 문제가 발생하지만(많은 다른 답변에서 볼 수 있듯이) 테이블에 일반적으로 여러 행이 포함되어 있기 때문에 그렇게 하도록 선택하는 것도 의미상 구멍으로 가득 차 있습니다. (대부분이 그러하듯이) 대소문자를 기반으로 명사를 변형하는 언어를 고려하면 이것은 더 분명합니다.

우리는 일반적으로 행에 대해 무언가를 하고 있기 때문에 대소문자에 이름을 넣지 않는 이유는 무엇입니까? 읽는 것보다 더 많이 쓰는 테이블이 있는 경우 이름을 날짜로 지정하지 않는 이유는 무엇입니까? 그것은 무언가의 테이블 입니다 . 왜 속격을 사용하지 않습니까? 테이블은 상태나 사용법에 관계없이 존재하는 추상 컨테이너로 정의되기 때문에 우리는 이것을 하지 않을 것입니다. 정확하고 절대적인 의미의 이유 없이 명사를 활용하는 것은 헛소리입니다.

굴절되지 않은 명사를 사용하는 것은 단순하고 논리적이며 규칙적이며 언어 독립적입니다.

Question 6

테이블에 단일 이름이 있어야 하는 규칙은 무엇입니까? 나는 항상 그것이 복수 이름이라고 생각했습니다.

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

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

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

다른 사람들이 언급했듯이 이것은 단지 지침일 뿐입니다. 당신과 당신의 회사/프로젝트에 적합한 규약을 선택하고 그것을 고수하십시오. 단수와 복수, 때로는 축약어와 때로는 그렇지 않은 단어 사이를 전환하는 것은 훨씬 더 악화됩니다.

Question 7

이것은 간단한 예로서 어떻습니까?

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

대

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

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

저는 단수에 한표를 던집니다.

Question 8

나는 엔터티 관계 다이어그램에서 엔터티는 클래스 이름이 단수인 것처럼 단수 이름으로 반영되어야 한다고 굳게 믿습니다. 인스턴스화되면 이름은 해당 인스턴스를 반영합니다. 따라서 데이터베이스에서 엔터티는 테이블(엔티티 또는 레코드의 모음)로 만들어질 때 복수형입니다. Entity, User는 테이블 Users로 만들어집니다. User라는 이름을 Employee 또는 귀하의 시나리오에 더 적합한 것으로 개선할 수 있다고 제안한 다른 사람들의 의견에 동의합니다.

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

Question 9

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

이유? mouse ⇒ mice 와 sheep ⇒ sheep 과 같이 영어 에 불규칙 복수형 이 있다는 사실 . 그런 다음 컬렉션이 필요하면 마우스 나 양을 사용하고 계속 진행합니다.

그것은 실제로 복수를 돋보이게 하는 데 도움이 되며, 나는 물건의 컬렉션이 어떻게 생겼는지 프로그래밍 방식으로 쉽게 결정할 수 있습니다.

그래서, 내 규칙은: 모든 것이 단수이고, 사물의 모든 컬렉션은 s가 추가된 단수입니다. ORM에도 도움이 됩니다.

Question 10

IMHO, 테이블 이름은 Customers 처럼 복수형 이어야 합니다.

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

Question 11

단수형. 나는 가장 논리적인 주장을 사지 않습니다. 모든 사람은 자신의 선호가 가장 논리적이라고 생각합니다. 당신이 무엇을 하든지 그것은 엉망입니다. 단지 규칙을 선택하고 그것을 고수하십시오. 우리는 매우 불규칙한 문법과 의미론을 가진 언어(보통 구어 및 서면 언어)를 매우 특정한 의미론을 가진 매우 규칙적인(SQL) 문법으로 매핑하려고 합니다.

내 주요 주장은 테이블을 집합이 아니라 관계로 생각한다는 것입니다.

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

AppUserGroup 관계는 어떤 엔터티가 AppUserGroups

AppUser_AppUserGroup AppUsers 와 AppUserGroups 가 어떻게 관련되어 있는지 알려줍니다.

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

다시 말해서, 개체와 그것들이 어떻게 관련되어 있는지 생각할 때 나는 단수로 관계를 생각하지만, 물론 컬렉션이나 집합의 개체를 생각할 때 컬렉션이나 집합은 복수입니다.

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

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

Question 12

나는 또한 복수형 을 사용할 것이고 앞서 언급한 사용자 딜레마와 함께 대괄호 접근 방식을 취합니다.

코드 아티팩트의 Users 컬렉션이 User 개체의 컬렉션인 것처럼 Users 테이블이 User 값의 컬렉션이라는 근본적인 이해를 바탕으로 데이터베이스 아키텍처와 애플리케이션 아키텍처 간에 균일성을 제공하기 위해 이 작업을 수행합니다.

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

Question 13

나는 개인적으로 집합을 나타내기 위해 복수 이름을 사용하는 것을 선호하는데, 내 관계적 마음에는 "소리"가 더 좋습니다.

바로 이 순간에 저는 회사의 데이터 모델을 정의하기 위해 단수 이름을 사용하고 있습니다. 직장에 있는 대부분의 사람들이 데이터 모델을 더 편안하게 느끼기 때문입니다. 때로는 개인 취향을 강요하는 대신 모든 사람의 삶을 더 쉽게 만들어야 합니다. (이것이 테이블 이름 지정에 대한 "모범 사례"가 무엇인지 확인하기 위해 이 스레드에서 끝난 방법입니다.)

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

나는 모든 사람이 좋아하는 맛이 무엇이든 상관없이 꿀을 곁들인 팬케이크를 좋아합니다. 그러나 내가 다른 사람들을 위해 요리를 한다면 그들이 좋아하는 것을 그들에게 제공하려고 노력할 것입니다.

Question 14

나는 실제로 항상 복수의 테이블 이름을 사용하는 것이 인기 있는 관례라고 생각했습니다. 지금까지 저는 항상 복수형을 사용했습니다.

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

자동차의 테이블은 이름이 차있을 것입니다 각 행은 차다. table.field 방식으로 필드와 함께 테이블을 지정하는 것이 모범 사례이며 단일 테이블 이름을 갖는 것이 더 읽기 쉽다는 것을 인정합니다. 그러나 다음 두 예에서는 전자가 더 의미가 있습니다.

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

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

Question 15

단수형. 사용자 행 표현 개체의 무리를 포함하는 배열을 'users'라고 부르지만 테이블은 '사용자 테이블'입니다. 테이블이 포함된 행 집합에 불과하다고 생각하는 것은 잘못된 것입니다. IMO; 테이블은 메타데이터이고 행 집합은 테이블 자체가 아니라 계층적으로 테이블에 연결됩니다.

물론 나는 항상 ORM을 사용하고, 복수의 테이블 이름으로 작성된 ORM 코드가 어리석어 보이는 데 도움이 됩니다.

Question 16

우리는 유사한 표준을 실행합니다. 스크립팅할 때 이름 주위에 [ ]를 요구하고 적절한 스키마 한정자가 있는 경우 - 주로 SQL 구문에 의한 향후 이름 획득에 대한 베팅을 헤지합니다.

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

이것은 과거에 우리의 영혼을 구했습니다. 일부 데이터베이스 시스템은 SQL 6.0에서 SQL 2005까지 10년 이상 실행되어 의도된 수명을 훨씬 넘어섰습니다.

Question 17

영어의 일부 명사(물, 수프, 현금)는 셀 수 없거나 셀 수 있게 만들 때 의미가 바뀌기 때문에(닭 대 닭, 고기 대 새) 복수형 테이블 이름을 좋아하지 않습니다. 또한 테이블 이름이나 열 이름에 약어를 사용하는 것을 싫어합니다. 그렇게 하면 이미 가파른 학습 곡선에 추가 기울기가 추가되기 때문입니다.

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

나는 또한 모든 ID 열의 이름을 ChickenId 또는 ChickensId 아닌 Id 로 지정하고 싶습니다(복수형은 이에 대해 어떻게 하나요?).

이 모든 것은 내가 데이터베이스 시스템에 대한 적절한 존중이 없기 때문입니다. Java의 습관과 게으름과 같은 객체지향 명명 규칙의 원트릭 포니 지식을 다시 적용하는 중입니다. 복잡한 SQL에 대해 더 나은 IDE 지원이 있었으면 합니다.

Question 18

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

Question 19

나는 CASE 구문을 사용하여 ER 다이어그램을 읽기 쉽게 만들어주는 단일 테이블 이름의 팬이지만 이러한 응답을 읽으면서 결코 잘 이해되지 않는다는 느낌을 받고 있습니까? 나는 그것을 개인적으로 좋아한다. 단일 테이블 이름을 사용하고, 관계에 동작 동사를 추가하고, 모든 관계에 대해 좋은 문장을 만들 때 모델이 얼마나 가독성이 좋은지에 대한 예제와 함께 좋은 개요가 있습니다. 20개 테이블 데이터베이스에는 다소 무리가 있지만 수백 개의 테이블과 복잡한 설계가 있는 DB가 있는 경우 가독성 좋은 다이어그램 없이 개발자가 이를 어떻게 이해할 수 있을까요?

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

테이블과 뷰에 접두사를 붙일 때 나는 그 관행을 절대적으로 싫어합니다. 나쁜 정보를 제공하기 전에 정보를 전혀 제공하지 마십시오. 개체에 대한 db를 검색하는 사람은 누구나 보기에서 테이블을 쉽게 구분할 수 있지만, tblUsers라는 테이블이 있는 경우 어떤 이유로 인해 향후 두 테이블로 재구성하기로 결정하고 이전 코드가 깨지지 않도록 통합하기로 결정했습니다. 이제 tblUsers라는 뷰가 있습니다. 이 시점에서 나는 두 가지 매력적이지 않은 옵션이 남아 있습니다. 일부 개발자를 혼란스럽게 할 수 있는 tbl 접두사로 명명된 보기를 남겨두거나, 중간 계층 또는 응용 프로그램이 내 새 구조 또는 이름 viewUsers를 참조하도록 다시 작성되도록 강제로 다른 계층을 강제할 수 있습니다. 이는 뷰 IMHO 가치의 상당 부분을 무효화합니다.

Question 20

테이블: 복수

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

모델: 단수

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

컨트롤러: 복수

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

그것은 어쨌든 그것에 대한 내 생각입니다.

Question 21

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

Oracle의 시스템 테이블은 singular 이름으로 지정됩니다. 그들 중 일부는 복수이지만. Oracle은 사용자 정의 테이블 이름에 복수형을 권장합니다. 그들이 한 가지를 추천하고 다른 것을 따르는 것은 의미가 없습니다. 이 두 소프트웨어 거인의 설계자가 서로 다른 규칙을 사용하여 테이블 이름을 지정했다는 것 역시 의미가 없습니다... 결국, 이 사람들은... 박사인가요?

학계에서는 추천이 단수였던 걸로 기억합니다.

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

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

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

Question 22

저는 그렇게 배웠기 때문에 항상 단수를 사용했습니다. 그러나 최근에 새로운 스키마를 생성하면서 오랜만에 이 규약을 유지하기로 적극 결정했습니다.... 더 짧기 때문입니다. 모든 테이블 이름 끝에 's'를 추가하는 것은 모든 테이블 이름 앞에 'tbl_'을 추가하는 것만큼 쓸모가 없어 보입니다.

Question 23

이것은 약간 중복될 수 있지만 주의를 기울이는 것이 좋습니다. 반드시 테이블의 이름을 바꾸는 것이 나쁜 것은 아니지만 표준화는 그저 그렇습니다. 표준 -- 이 데이터베이스는 이미 "표준화"되어 있을 수 있지만 심하게는 :) -- 이 데이터베이스가 이미 존재하고 아마도 2개 이상의 테이블로 구성되어 있다는 점을 감안할 때 일관성을 더 나은 목표로 제안할 것입니다.

전체 데이터베이스를 표준화할 수 없거나 최소한 그 목적을 위해 작업할 계획이 없다면 테이블 이름은 빙산의 일각에 불과하고 당면한 작업에 집중하고 이름이 잘못된 개체의 고통을 견디는 것은 아마도 귀하의 최대 관심사 --

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

my2cents ---

Question 24

가능한 대안:

테이블 이름을 SystemUser로 바꿉니다.
대괄호 사용
복수의 테이블 이름을 유지하십시오.

대괄호를 사용하는 IMO는 기술적으로 가장 안전한 접근 방식이지만 다소 번거롭습니다. IMO 그것은 6개 중 6개, 다른 6개이며, 귀하의 솔루션은 실제로 개인/팀 선호도에 따라 결정됩니다.

Question 25

내 생각은 컨테이너를 정의하는 방법에 따라 의미론에 있습니다. 예를 들어 "사과 봉지" 또는 간단히 "사과" 또는 "사과 봉지" 또는 "사과"입니다.

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

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

내 결론은 둘 다 괜찮지만 테이블을 참조할 때 당신(또는 테이블과 상호 작용하는 사람들)이 접근하는 방법을 정의해야 한다는 것입니다. "도끼 테이블" 또는 "x 테이블"

Question 26

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

Question 27

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

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

이 방법을 사용하면 개체 간의 다대다 관계를 저장하는 테이블 이름을 복수로 예약할 수도 있습니다.

테이블과 열 이름에도 예약어를 사용하지 않으려고 합니다. 여기서 문제의 경우 User의 예약어를 사용하는 테이블을 캡슐화할 필요를 피하기 위해 Users에 대한 단일 규칙에 반대되는 것이 더 합리적입니다.

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

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

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

Question 28

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

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

Question 29

나는 항상 그것이 어리석은 대회라고 생각했습니다. 나는 복수의 테이블 이름을 사용합니다.

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

Question 30

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

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

Question 31

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

함수는 키 집합의 각 요소가 매핑 에서 최대 한 번 발생하는 두 집합 간의 외적 하위 집합으로 정의할 수 있습니다. 따라서 그러한 관점에서 나오는 용어는 단수 경향이 있습니다. 함수(예: 대수 및 람다 미적분학)와 관련된 다른 수학적 및 계산 이론에서 동일한 단수(또는 최소한 복수가 아닌) 규칙이 표시됩니다.

Lodash와 Underscore.js의 차이점 (0)	2022.01.14
동적으로 생성된 요소에 대한 이벤트 바인딩? (0)	2022.01.14
Python에서 경과 시간을 측정하는 방법은 무엇입니까? (0)	2022.01.14
pip를 사용하여 특정 패키지 버전 설치 (0)	2022.01.14
... 값에 삽입( SELECT ... FROM ... ) (0)	2022.01.14

No error , No gain

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

'etc. > StackOverFlow' 카테고리의 다른 글

'etc./StackOverFlow'의 다른글

티스토리툴바

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

'etc. > StackOverFlow' 카테고리의 다른 글

'etc./StackOverFlow'의 다른글

관련글

티스토리툴바