복수 대 단수 테이블 이름

새 데이터베이스를 만들 때 테이블 이름을 어떻게 지정해야합니까?

단수형 Client또는 복수형 : Clients?

당신에게 달려 있습니다. 그래도 일관성을 유지하십시오.

개인적으로 나는 각 행이 무엇을 저장하는지에 따라 단수형, 제품, 사용자, 품목 등을 선호합니다.

이것은 단일 엔티티 / 유형을 사용하는 모델링 (객체 역할 모델링을 통해)과 일치합니다.

편집하다:

한 가지 이유는 당신이 링크 테이블이있는 경우 복수 실패이다 :
Orders, Products줄 것이다 OrderProducts나 OrdersProducts. 둘 다 올바른 소리가 아님

또는 히스토리 테이블 (물론이를 위해 스키마를 사용할 수 있음) :
Orders-> OrdersHistory또는 (no!) OrdersHistories? 하지 않을까요 Order> - OrderHistory더 나은?

단수와 복수의 테이블 이름에 관해서, 주제는 논란의 여지가있는 것처럼 보이지만 그렇게해서는 안됩니다.

테이블은 여러 레코드의 모음 인 반면 테이블에는 포함 된 한 가지 유형의 레코드의 정의에 따라 이름이 지정됩니다. 테이블에 포함 된 레코드 유형과 이름이 다른 경우 테이블에 복수 이름을 지정하여 예를 들어 여러 직원 레코드를 포함하는 Employees 테이블을 가질 수 있습니다. 그러나 SQL 디자이너는 테이블과 레코드 유형에 별도의 이름을 제공하지 않았습니다.

레코드 유형의 이름 (및 확장명으로 테이블 이름)이 하나의 레코드를 설명하는 데 사용하는 클래스 이름과 일치하므로 단일 형식으로 유지되는 경우 데이터를 사용하는 객체 지향 프로그램의 경우 논리적으로 더 잘 작동합니다. .

그런 다음 프로그램에서 컬렉션을 식별하려면 복수를 사용하거나 EmployeeList 또는 EmployeeArray와 같은 적절한 수정자를 사용하는 것이 좋습니다.

자동 코드 생성을위한 불규칙 복수형과 프로그램에서 복수형의 형성에 대해 다른 언어 배경이나 아이디어를 가진 프로그래머도 문제가 있습니다.

영어는 적절하고 적절한 프로그래밍 언어가 아니며 데이터베이스 및 프로그램 설명을 영어와 일치 시키려고하는 것은 그 문장 중 하나를 읽는 것이 더 좋기 때문에 실수입니다.

@gbn의 답변 과 마찬가지로 이것이 가장 선호하는 문제라고 생각하고 그와 마찬가지로 원하는 모든 선택을 적어도 모든 DB에 적용하는 것이 좋습니다. 일관성은 그만한 가치가 있습니다.

그러나 선호하는 것은 SELECT진술 에서 복수가 더 잘 들리는 것입니다 .

SELECT Id, Name, Status 
FROM   Persons
WHERE  Status <> 5  --5 meaning deleted

나는이 경우 적어도 테이블에 여러 사람이 있고 그 중 몇 명은 고객에게 반환된다는 것을 의미합니다.

"순서"는 예약어입니다. "주문"은 아닙니다

"사용자"는 예약어입니다. "사용자"는 아닙니다

"세션"은 예약어입니다. "세션"은 아닙니다

"결과"는 예약어입니다. "결과"는 아닙니다

"상대적"은 예약어입니다. "친척"은 아닙니다

...

이는 업무용 데이터베이스에 들어갈 수있는 일반적인 단어처럼 보입니다. 복수 단어는 단수 단어보다 핵심 단어로 덜 일반적으로 보입니다. 따라서 SQL 키워드와의 충돌을 피하기 위해 복수 테이블 이름을 사용하는 것이 좋습니다.

SQL 테이블에는 복수 이름이 있어야한다고 생각합니다. 그것은 훨씬 더 잘 읽습니다.

장부 기록표를 장부라고합니다. ORM은 동일한 규칙을 사용해야합니다. Books 개체는 컬렉션이며 Books Table의 모든 레코드를 관리합니다. Book 개체는 단일 레코드보다 우선합니다.

이것은 코딩을 더욱 자연스럽게 만듭니다.

select name, publication_date from books where publication_date > '2000-01-01';

books = Books()
for book in books.get("publication_date >= '2000-01-01'"):
    print book.name

몇 년 동안 프로그래밍 작업을 한 후에 나는 복수화가 불필요하게 복잡하다는 결론을 내 렸습니다. KISS 철학에 따르면 프로그래머는 시간과 효율성의 이유로 모든 문제에 대한 가장 게으르고 가장 쉬운 해결책을 찾기 위해 노력해야한다고 생각합니다. 따라서 단수는 모든 시나리오에서 필요한 작업이 줄어 듭니다.

매우 개인적인 것입니다. 저는 30 년 동안 단수형을 사용해 왔습니다. 하지만 왜 사람들이 복수를 좋아하는지 알 수 있습니다. 책 저자가 틀렸다고 생각하기 때문에 책-저자는 흥미 롭습니다. 책에는 한 명 이상의 저자가있을 수 있습니다. 그리고 저자는 하나 이상의 책을 썼을 수도 있습니다 (예 : 공동 저술). 또한 한 명 이상의 저자가 쓴 책을 어떻게 다루는 지에 달려 있습니다. 다른 답변에 동의합니다. 하나를 선택하고 일관성을 유지하십시오. 예약어 문제와 관련하여. 해결 방법 이름을 찾는 것이 어렵지 않다고 생각합니다. 사용자-> app_user, 세션-> app_session, 주문-> customer_order

우리는 다른 관점에서 사물을보고 있으며 두 캠프는 다음과 같이 식별됩니다.

단수 ( "사용자")
테이블 이름과 여러 행을 포함 할 수있는 컨테이너를 나타내는 사실을 상관시키는 사람입니다.

따라서 "사용자 컨테이너"는 여러 행을 포함 할 수 있습니다.

복수 ( "사용자")
테이블 이름과 상관 관계가없는 사람은 컨테이너를 나타냅니다. 물론 그들은 그것이 컨테이너라는 것을 알고 있지만 이름에는 없습니다.

예를 들어
"계란 상자"에는 여러 개의 알이 들어있을 수 있지만 용기 참조가 이름에 들어있어 알이 여러 개일 가능성이 있습니다. 그러나 단일 테이블 이름 "user"를 사용하면 컨테이너 참조가 이름에 없습니다. 예를 들어 "user_container"는 복수 이름을 선호하는 사람들에게 적합 할 것입니다.

나는 이것이 또한 수년간의 복수 관행과 대부분의 온라인 교육 자료 때문이라고 생각합니다.

이 모든 것이 기술적으로 단일 컨테이너의 이름을 지정하고 컨테이너가 여러 (또는 단일) 행을 포함 할 수 있다는 점에서 단수를 말하면 더 정확하다고 생각합니다.
명명 된 컨테이너를 내용에 정신적으로 연결하지 않고 (컨테이너가 여러 항목을 허용하는) 테이블 이름을 내용에 정신적으로 연결하면 사람들이 잘못 보인다 (여러 행에는 복수 이름이 필요함).

항상 옳고 그름은 없지만, 시나리오에 적합한 것이 무엇인지, 그리고 무엇을 선택하든 중요하게 일치하는 것이 중요합니다.

프로젝트를 단독으로 수행하고 있고 자신이 가장 좋아하는 것을 취하거나 선호도에 따라 갈 실제적인 이유가 없다면. 개발자 팀에서 동일한 방식으로 적용하고 만장일치로 결정하십시오.