새 프로젝트를 시작하고 처음부터 테이블 및 열 이름을 가져오고 싶습니다. 예를 들어 나는 항상 테이블 이름에 복수를 사용했지만 최근에 배운 단수는 맞습니다.

따라서 "user"라는 테이블이 있고 사용자 만 가질 수있는 제품이있는 경우 테이블의 이름을 "user_product"또는 "product"로 지정해야합니까? 이것은 일대 다 관계입니다.

또한 각 제품에 대해 몇 가지 제품 설명이있는 경우 "user_product_description"또는 "product_description"또는 "description"입니까? 물론 올바른 외래 키가 설정되어 있습니다. 이름 만 설명하면 문제가 될 것입니다. 사용자 설명이나 계정 설명 등을 가질 수도 있기 때문입니다.

열이 두 개인 순수한 관계형 테이블 (다 대다)을 원한다면 어떻게 될까요? "user_stuff"또는 "rel_user_stuff"와 같은 것입니까? 첫 번째 경우 "user_product"와 다른 점은 무엇입니까?

어떤 도움이라도 높이 평가할 수 있으며 여러분이 권장하는 명명 규칙이 있다면 자유롭게 연결하십시오.

감사

표 • 이름

최근에 배운 단수가 맞다

예. 이방인들을 조심하십시오. 표 이름에 복수 는 표준 자료를 읽지 않고 데이터베이스 이론에 대한 지식이없는 사람의 확실한 표시입니다.

표준에 대한 몇 가지 훌륭한 점은 다음과 같습니다.

• 그들은 모두 서로 통합되어 있습니다
• 그들은 함께 일한다
• 그것들은 우리의 생각보다 더 큰 마음으로 기록되었으므로 토론 할 필요가 없습니다.

표준 테이블 이름은 테이블의 전체 내용이 아닌 모든 언어에 사용되는 테이블의 각 행 을 나타냅니다 ( Customer테이블에 모든 고객이 포함되어 있음을 알고 있음 ).

관계, 동사구

모델링 된 진정한 관계형 데이터베이스 (1970 이전의 레코드 파일링 시스템 ( Record IDs이는 편의상 SQL 데이터베이스 컨테이너로 구현되는 특징)과 반대 )에서 :

• 테이블은 데이터베이스 의 주제 이므로 명사 이며 다시 단수입니다.
• 표 사이의 관계 는 명사 사이에서 발생 하는 동작 이므로 동사입니다 (즉, 임의로 번호가 지정되거나 이름이 지정되지 않음).
• 그것은 이다 술어
• 데이터 모델에서 직접 읽을 수있는 모든 것 (끝에 내 예제를 참조하십시오)
• (독립 테이블 (계층 구조의 최상위 부모)의 술어는 독립적이라는 것입니다)
• 따라서 동사구 (Verb Phrase) 는 신중하게 선택되므로 가장 의미가 있고 일반적인 용어는 사용하지 않아도됩니다 (경험이 있으면 더 쉬워집니다). 동사구 (Verb Phrase)는 모델을 해결하는데 도움을주기 때문에 모델링 중에 중요합니다. 관계를 명확하게하고 오류를 식별하며 테이블 이름을 수정합니다.

Diagram_A

물론 관계는 CONSTRAINT FOREIGN KEY자식 테이블에서 와 같이 SQL에서 구현됩니다 (자세한 내용은 나중에 설명). 다음은 동사 구 (모델), 모델 이 나타내는 술어 (모델에서 읽을) 및 FK 제약 조건 이름입니다 .

    Initiates
    Each Customer Initiates 0-to-n SalesOrders
    Customer_Initiates_SalesOrder_fk

표 • 언어

그러나 테이블, 특히 술어 또는 기타 문서와 같은 기술 언어로 테이블을 설명 할 때는 자연스럽게 영어로 된 단수 및 복수를 사용합니다. 표의 이름은 단일 행 (관계)의 이름이며 언어는 파생 된 각 행 (파생 관계)을 나타냅니다.

    Each Customer initiates zero-to-many SalesOrders

아니

    Customers have zero-to-many SalesOrders 

따라서 "user"테이블이 있고 사용자 만 가질 수있는 제품이있는 경우 테이블의 이름을 "user-product"또는 "product"로 지정해야합니까? 이것은 일대 다 관계입니다.

(이것은 네이밍-컨벤션 질문이 아니라 DB 디자인 질문입니다.) user::product1 :: n 인지 는 중요하지 않습니다 . 중요한 것은 product별도의 엔티티인지 여부와 독립 테이블 인지 여부 입니다. 그것은 스스로 존재할 수 있습니다. 따라서 product아닙니다 user_product.

그리고 만약 product의 상황에서만 존재 한다면 user, 즉. 그것은 인 종속 테이블 그러므로 user_product.

Diagram_B

또한 각 제품에 대해 몇 가지 제품 설명이있는 경우 "사용자 제품 설명"또는 "제품 설명"또는 "설명"입니까? 물론 올바른 외래 키가 설정되어 있습니다. 이름 만 설명하면 문제가 될 것입니다. 사용자 설명이나 계정 설명 등을 가질 수도 있기 때문입니다.

맞습니다. 어느 user_product_descriptionXOR은 product_description상기 내용을 토대로, 정확합니다. 다른 것과 구별하는 것이 xxxx_descriptions아니라 접두사가 부모 테이블 인 접두어를 이름에 부여하는 것입니다.

열이 두 개인 순수한 관계형 테이블 (다 대다)을 원한다면 어떻게 될까요? "user-stuff"또는 "rel-user-stuff"와 같은 것입니까? 그리고 첫 번째 경우, 예를 들어 "사용자 제품"과 무엇을 구별 할 수 있습니까?

1. 관계형 데이터베이스의 모든 테이블이 순수한 관계형 정규화 된 테이블이기를 바랍니다. 이름에서이를 식별 할 필요는 없습니다 (그렇지 않으면 모든 테이블은 rel_something).

2. 논리 레벨에서 엔티티로 존재하지 않는 논리 n :: n 관계를 실제 테이블 로 해석하는 두 상위의 PK 만 포함 하는 경우 연관 테이블 입니다. 예, 일반적으로 이름은 두 개의 상위 테이블 이름의 조합입니다.

   • 동사 구는 부모의 부모와 관련이 있기 때문에 동사 구문은 자식 테이블을 무시하고 부모 테이블에서 부모 테이블에서 부모 테이블로 적용됩니다.

     Diagram_C

   • 연관 테이블 이 아닌 경우 (즉, 두 PK 외에 데이터가 포함 된 경우) 적절하게 이름을 지정하고 동사 구가 관계의 끝에있는 부모가 아닌 여기에 적용됩니다.

     Diagram_D

3. 두 개의 user_product테이블로 끝나면 데이터를 정규화하지 않았다는 매우 큰 신호입니다. 따라서 몇 단계 뒤로 이동하여 테이블 이름을 정확하고 일관되게 지정하십시오. 그러면 이름이 스스로 해결됩니다.

명명 규칙

어떤 도움이라도 높이 평가할 수 있으며 여러분이 권장하는 명명 규칙이 있다면 자유롭게 연결하십시오.

당신이하고있는 일은 매우 중요하며, 모든 수준에서 사용의 용이성과 이해에 영향을 줄 것입니다. 따라서 처음부터 최대한 이해하는 것이 좋습니다. SQL로 코딩을 시작할 때까지 대부분의 관련성은 명확하지 않습니다.

1. 사례 는 처음으로 해결해야 할 항목입니다. 모든 캡은 허용되지 않습니다. 특히 사용자가 테이블에 직접 액세스 할 수있는 경우 대소 문자를 혼합하는 것이 정상입니다. 내 데이터 모델을 참조하십시오. 찾는 사람이 소문자 만있는 일부 비정형 NonSQL을 사용하는 경우, 예를 들어 밑줄을 포함 시키면됩니다.

2. 응용 프로그램 또는 사용 포커스가 아닌 데이터 포커스를 유지하십시오 . 2011 년 이후 우리는 1984 년부터 Open Architecture 를 사용했으며 데이터베이스는 데이터베이스를 사용하는 앱과 독립적이어야합니다.

   그렇게하면 앱이 커질수록 하나의 앱에서 사용하는 것보다 이름이 의미가 있으며 수정이 필요하지 않습니다. 단일 앱에 완전히 포함 된 데이터베이스는 데이터베이스가 아닙니다. 데이터 요소의 이름은 데이터로만 지정하십시오.

3. 매우 신중하고 테이블과 열의 이름을 매우 정확하게 지정하십시오 . 데이터 유형 인 UpdatedDate경우 사용하지 마십시오 . 복용량이 포함되어 있으면 사용하지 마십시오 .DATETIMEUpdatedDtm_description

4. 데이터베이스에서 일관성 을 유지하는 것이 중요 합니다. NumProduct한 곳에서 제품 수를 나타내 ItemNo거나 ItemNum다른 곳에서 사용하여 품목 수를 나타내지 마십시오 . 사용 NumSomething번호-, 그리고 위해 SomethingNo또는 SomethingId지속적으로, 식별자.

5. 열 이름 앞에 테이블 이름이나 짧은 코드 (예 :)를 접두어로 두지 마십시오 user_first_name. SQL은 이미 테이블 이름을 규정 자로 제공합니다.

       table_name.column_name  -- notice the dot
   

6. 예외 :

   • 첫 번째 예외는 PK의 경우 항상 조인으로 코딩하고 데이터 열에서 키가 두드러 지도록하기 위해 특별한 처리가 필요하다는 것입니다. 항상 사용하지 user_id, 결코 id.

     • 이 있음을 유의 하지 접두사로서 사용 테이블 이름이지만 키의 구성 요소에 대한 적절한 이름 설명 : user_id컬럼 인 것을 식별하는 아닌 사용자 id의 user테이블.
       • (물론 대리인이 파일에 액세스하고 관계형 키가없는 레코드 파일링 시스템은 제외하고 하나만 있으면됩니다).
     • PK가 FK로 운반 (마이그레이션) 될 때마다 키 열에 대해 정확히 동일한 이름을 사용하십시오.
     • 따라서 user_product테이블은 user_idPK의 구성 요소로 사용 (user_id, product_no)됩니다.
     • 코딩을 시작할 때 이것의 관련성이 명확 해집니다. 첫째, id많은 테이블을 사용하면 SQL 코딩에서 쉽게 섞일 수 있습니다. 둘째, 다른 사람들은 초기 코더가 자신이 무엇을하려고했는지 전혀 모른다고 생각합니다. 키 열이 위와 같이 처리되면 둘 다 방지하기 쉽습니다.

   • 두 번째 예외는 동일한 상위 테이블 테이블을 참조하는 둘 이상의 FK가 하위에 포함 된 경우입니다. 당으로 관계형 모델 , 사용의 역할 이름은 예를 들면 의미 나 사용을 차별화한다. AssemblyCode그리고 ComponentCode두 PartCodes. 이 경우 미분화 를 사용 하지 마십시오PartCode . 정확해야합니다.

     Diagram_E

7. 접두사
   100 개가 넘는 테이블이있는 경우 테이블 이름 앞에 제목 영역을 붙입니다.

   REF_
OE_주문 항목 클러스터의 참조 테이블 등

   논리적 수준이 아닌 물리적 수준에서만 (모델을 복잡하게 만듭니다).

8. 접미사
   테이블에는 접미사를 사용하지 말고 항상 다른 모든 것에 접미사를 사용하십시오. 즉, 데이터베이스의 논리적이고 정상적인 사용에는 밑줄이 없습니다. 그러나 관리 측면에서 밑줄은 구분 기호로 사용됩니다.

   _V보기 ( TableName물론 메인 을 앞에두고)
   _fk외래 키 (열 이름이 아닌 제약 조건 이름)
   _cac캐시
   _seg세그먼트
   _tr트랜잭션 (저장된 프로 시저 또는 함수)
   _fn함수 (트랜잭션 없음) 등

   형식은 테이블 또는 FK 이름, 밑줄 및 작업 이름, 밑줄 및 마지막 접미사입니다.

   서버가 오류 메시지를 표시 할 때 이것은 매우 중요합니다.

   ____blah blah blah error on object_name

   위반 한 대상과 수행하려는 작업을 정확히 알고 있습니다.

   ____blah blah blah error on Customer_Add_tr

9. 외래 키 (열이 아닌 제약 조건) FK의 가장 좋은 이름은 동사 구문 ( "각"및 카디널리티 빼기)을 사용하는 것입니다.

   Customer_Initiates_SalesOrder_fk
Part_Comprises_Component_fk
Part_IsConsumedIn_Assembly_fk

   (a) Parent_Child_fk시퀀스를 Child_Parent_fk찾을 때 올바른 정렬 순서로 표시되며 (b) 관련된 자식, 우리가 추측하는 내용, 어느 부모를 항상 알고 있기 때문에 시퀀스를 사용 하지 마십시오 . 그러면 오류 메시지가 유쾌합니다.

   ____ Foreign key violation on Vendor_Offers_PartVendor_fk.

   동사 구문이 식별 된 데이터를 모델링하려는 사람들에게 유용합니다. 나머지는 기록 파일 시스템 등을 사용하십시오 Parent_Child_fk.

10. 인덱스는 특별하므로 각 문자 위치는 1에서 3까지 순서대로 구성된 고유 한 명명 규칙이 있습니다 .

    U고유 또는 _비 고유
    C클러스터 또는 _비 클러스터
    _구분 기호

    나머지 :

    • 키가 하나의 열이거나 매우 적은 열인 경우 :
      ____ColumnNames

    • 키가 몇 열 이상인 경우 :
      ____ PK기본 키 (모델 별)
      ____ AK[*n*]대체 키 (IDEF1X 용어)

    인덱스 이름 에는 테이블 이름이 항상 필요 하지 않습니다.table_name.index_name.

    그래서 때 Customer.UC_CustomerId또는 Product.U__AK오류 메시지가 나타납니다, 그것은 당신에게 의미있는 무엇인가를 알려줍니다. 테이블의 인덱스를 보면 쉽게 구별 할 수 있습니다.

11. 자격을 갖춘 전문가를 찾아 따르십시오. 그들의 디자인을보고 그들이 사용하는 명명 규칙을주의 깊게 연구하십시오. 이해하지 못하는 것에 대한 구체적인 질문을하십시오. 반대로, 명명 규칙이나 표준에 대한 관심이 거의없는 사람은 지옥처럼 뛰십시오. 몇 가지 시작해보십시오.

    • 그들은 위의 모든 것의 실제 예를 포함합니다. 이 글타래에서 이름을 다시 물어보세요.
    • 물론이 모델은 명명 규칙 외에 다른 여러 표준을 구현합니다 . 지금은 무시하거나 특정 질문을 자유롭게 할 수 있습니다 .
    • 그것들은 각각 몇 페이지이고, Stack Overflow의 인라인 이미지 지원은 새를위한 것이며 다른 브라우저에서 일관되게로드되지 않습니다. 링크를 클릭해야합니다.
    • PDF 파일은 전체 탐색 기능이 있으므로 파란색 유리 버튼 또는 확장이 식별 된 객체를 클릭하십시오.
    • 관계형 모델링 표준에 익숙하지 않은 독자는 IDEF1X 표기법이 도움이 될 수 있습니다.

표준 준수 주소를 사용한 주문 입력 및 재고

PHP / MyNonSQL을위한 간단한 오피스 간 게시판 시스템

완전한 시간 기능을 갖춘 센서 모니터링

질문에 대한 답변

^{주석 공간에서 합리적으로 대답 할 수는 없습니다.}

Larry Lustig :
... 가장 간단한 예조차도 보여줍니다.
고객이 0 대다 제품을 가지고 있고 제품에 1 대다 구성 요소가 있고 구성 요소가 1 대다 공급 업체를 가지고 있고 공급 업체가 0을 판매하는 경우 일대 다 구성 요소 및 SalesRep에는 일대 다 고객이 있습니다. 고객, 제품, 구성 요소 및 공급 업체를 보유하고있는 "자연"이름은 무엇입니까?

귀하의 의견에는 두 가지 주요 문제가 있습니다.

1. 당신은 당신의 예를 "가장 사소한"것으로 선언하지만, 그것은 아무것도 아닙니다. 그런 모순으로, 기술적으로 능력이 있다면 진지한 지 확실하지 않습니다.

2. 이 "사소한"추측에는 몇 가지 총 정규화 (DB Design) 오류가 있습니다.

   • 수정하기 전까지는 부자연스럽고 비정상적이며 아무런 의미가 없습니다. 비정상 _1, 비정상 _2 등의 이름을 지정할 수도 있습니다.

   • 아무것도 공급하지 않는 "공급자"가 있습니다. 순환 참조 (불법 및 불필요); 구매의 기초로 상용 장비 (예 : 송장 또는 SalesOrder)없이 제품을 구매하는 고객 (또는 고객이 "자신의"제품을 사용합니까?) 해결되지 않은 다 대다 관계; 기타

   • 이것이 정규화되고 필요한 테이블이 식별되면 이름이 분명해집니다. 당연히.

어쨌든 귀하의 쿼리를 처리하려고 노력할 것입니다. 그것은 당신이 무엇을 의미하는지 알지 못하고 감각을 더해야한다는 것을 의미합니다. 심각한 오류가 너무 많아서 나열 할 수 없으며, 예비 사양이 주어지면 모든 오류를 수정했다고 확신 할 수 없습니다.

• 제품이 구성 요소로 구성되어 있으면 제품이 조립품이고 구성 요소가 둘 이상의 조립품에 사용된다고 가정합니다.

• 또한 "공급 업체는 0 대다 구성 요소 판매 "이므로 제품이나 어셈블리를 판매 하지 않으므로 구성 요소 만 판매합니다.

추론과 정규화 모형

모르는 경우 사각형 모퉁이 (독립)와 둥근 모퉁이 (종속)의 차이가 큰 경우 IDEF1X 표기법 링크를 참조하십시오. 마찬가지로 실선 (식별) 대 파선 (비 식별).

... 고객, 제품, 구성 요소 및 공급 업체를 보유하고있는 "자연"이름은 무엇입니까?

• 고객
• 생성물
• 컴포넌트 (또는 하나의 사실이 다른 것을 식별한다는 것을 인식하는 사람들을위한 AssemblyComponent)
• 공급 업체

표를 해결 했으므로 문제를 이해하지 못합니다. 특정 질문을 게시 할 수 있습니다 .

VoteCoffee :
2 개의 테이블 (user_likes_product, user_bought_product) 사이에 다중 관계가 존재하는 Ronnis의 예에서 게시 한 시나리오를 어떻게 처리하고 있습니까? 이해하지 못할 수도 있지만 자세한 설명을 사용하여 테이블 이름이 중복되는 것 같습니다.

정규화 오류가 없다고 가정하면 User likes Product테이블이 아닌 술어입니다. 혼동하지 마십시오. 주제, 동사 및 술어와 관련된 제 답변, 바로 위의 래리에 대한 나의 답변을 참조하십시오.

• 각 테이블에는 팩트 세트 가 포함됩니다 (각 행은 사실임). 술어 (또는 명제)는 사실이 아니며 사실 일 수도 있고 아닐 수도 있습니다.

  • 관계형 모델은 (더 일반적으로 첫 번째 순서 논리라고도 함) 우선 주문 술어 미적분을 기반으로합니다. 술어는 단순하고 정확한 영어로 된 단절 문장으로, 참 또는 거짓으로 평가됩니다.

  • 또한 각 테이블은 하나가 아닌 많은 술어를 나타내거나 구현 합니다.

• 쿼리는 참 (사실이 존재 함) 또는 거짓 (사실이 존재하지 않음)이되는 술어 (또는 여러 체인으로 묶여있는)의 테스트입니다.

• 따라서 내 답변 (명명 규칙)에서 행, 팩트 및 술어에 대해 테이블의 이름을 지정해야하며, 술어는 반드시 문서화되어야합니다 (데이터베이스 문서의 일부 임). .

• 이것이 중요하지 않다는 제안은 아닙니다. 그것들은 매우 중요하지만 여기서는 쓰지 않겠습니다.

• 그럼 빨리. 때문에 관계형 모델이 FOPC에 설립, 전체 데이터베이스는 FOPC 선언 세트, 술어의 집합이라고 할 수있다. 그러나 (a) 많은 유형의 술어가 있으며 (b) 테이블은 하나의 술어를 나타내지 않습니다 ( 많은 술어 및 다른 유형 의 술어 의 실제 구현입니다 ).

• 따라서 "the"술어에 대한 테이블의 이름은 터무니없는 개념입니다.

• "이론가"는 몇 가지 술어 만 알고 있으며, RM 이 FOL에서 발견되었으므로 전체 데이터베이스가 술어 세트와 다른 유형 이라는 것을 이해하지 못합니다 .

  • 그리고 물론 그들은 그들이 아는 몇 가지 중에서 터무니없는 것을 선택합니다 EXISTING_PERSON. PERSON_IS_CALLED. 슬퍼하지 않았다면 재미있을 것입니다.

  • 또한 표준 또는 원자 테이블 이름 (행 이름 지정)은 모든 언어 (테이블에 첨부 된 모든 술어 포함)에 대해 훌륭하게 작동합니다. 반대로, 바보 "표는 술어를 나타냅니다"이름은 할 수 없습니다. 술어에 대해 거의 이해하지 않지만 달리 지연하는 "이론가"에게는 괜찮습니다.

• 데이터 모델과 관련된 술어는 모델로 표시 되며 두 가지 순서로되어 있습니다.

  1. 단항 술어
     첫 번째 세트는 텍스트 가 아니라 다이어그램 입니다. 표기법 자체 . 여기에는 다양한 존재가 포함됩니다. 제약 중심; 설명자 (속성) 술어.

     • 물론 이는 표준 데이터 모델을 '읽을'수있는 사람 만이 해당 술어를 읽을 수 있음을 의미합니다. 그렇기 때문에 텍스트 전용 사고 방식에 의해 심하게 구부러진 "이론가"가 데이터 모델을 읽을 수없는 이유는 1984 년 이전의 텍스트 전용 사고 방식을 고수 한 이유입니다.

  2. 이진 조건 자
     두 번째 집합은 팩트 간의 관계 를 형성하는 것입니다 . 이것은 관계 라인입니다. 동사 구문 (위에 자세히 설명 되어 있음)은 구현 된 쿼리 ( 제안을 통해 테스트 할 수 있음)를 나타냅니다. 그보다 더 명확하게 표현할 수는 없습니다.

     • 따라서 표준 데이터 모델에 능숙한 사람에게는 관련있는 모든 술어 가 모델에 문서화됩니다. 별도의 술어 목록이 필요하지 않습니다 (그러나 데이터 모델에서 모든 것을 '읽을'수없는 사용자!).

• 여기 에 술어를 나열한 데이터 모델 이 있습니다. 이 예제는 Existential 등의 술어와 관계 항목을 보여주기 때문에 선택했습니다. 나열되지 않은 유일한 술어는 설명자입니다. 여기서는 구도자의 학습 수준으로 인해 그를 사용자로 취급하고 있습니다.

따라서 두 상위 테이블 사이에 둘 이상의 하위 테이블이있는 이벤트는 문제가되지 않으며 기존 사실을 컨텐츠로 지정하여 이름을 지정하고 이름을 정규화하십시오.

연관 테이블 (Associative Tables)의 관계 이름에 대한 동사구 (Verb Phrase)에 적용한 규칙이 여기에 적용됩니다. 여기에 언급 된 모든 요점을 포괄 하는 술어 대 테이블 토론이 있습니다.

술어를 올바르게 사용하고 사용법을 사용하는 방법 (여기서 주석에 응답하는 것과는 매우 다른 컨텍스트)에 대한 간단한 설명을 보려면 이 답변을 방문 하여 술어 섹션으로 스크롤 하십시오.

Charles Burns :
순서대로, Oracle 스타일의 객체는 규칙에 따라 숫자와 그 다음 번호를 저장하는 데 사용되었습니다 (예 : "add 1"). Oracle에는 자동 ID 테이블이 없기 때문에 일반적으로 테이블 PK의 고유 ID를 생성합니다. foo (id, somedata) 값에 삽입 (foo_s.nextval, "data"...)

이것이 바로 Key 또는 NextKey 테이블입니다. 이름을 이렇게 지정하십시오. SubjectArea가있는 경우 COM_NextKey를 사용하여 데이터베이스 전체에서 공통임을 표시하십시오.

Btw, 이것은 키를 생성하는 매우 열악한 방법입니다. 전혀 확장 할 수 없지만 Oracle의 성능으로 인해 "정상"일 것입니다. 또한 데이터베이스에는 해당 영역과 관계가없는 대리자로 가득 차 있습니다. 이는 매우 열악한 성능과 무결성 부족을 의미합니다.

단수와 복수 : 하나를 골라 붙입니다.

열 앞에 접두사 / 접미사 / 접두사를 붙여서는 안됩니다. 테이블도 마찬가지입니다. EMPLOYEE_T 또는 TBL_EMPLOYEES 테이블의 이름을 두지 마십시오. 두 번째 뷰로 바뀌면 상황이 혼란스러워집니다.

varchar의 경우 "vc_firstname"또는 "flavour_enum"과 같은 유형 정보를 이름에 포함하지 마십시오. 또한 "department_fk"또는 "employee_pk"와 같은 열 이름에 제약 조건을 포함하지 마십시오.

사실, 내가 생각할 수있는 * 수정에 대한 유일한 좋은 점은 같은 예약어를 사용할 수 있다는 것입니다 where_t, tbl_order, user_vw. 물론, 그 예에서 복수를 사용하면 문제가 해결되었을 것입니다. :)

모든 키의 이름을 "ID"로 지정하지 마십시오. 같은 것을 가리키는 키는 모든 테이블에서 같은 이름을 가져야합니다. 사용자 테이블과 사용자를 참조하는 모든 테이블에서 사용자 ID 열을 USER_ID라고 할 수 있습니다. 다른 사용자가 Message (sender_user_id, receiver_user_id)와 같이 다른 역할을 수행하는 경우에만 이름을 바꿀 수 있습니다. 더 큰 쿼리를 처리 할 때 실제로 도움이됩니다.

CaSe 관련 :

thisiswhatithinkofalllowercapscolumnnames.

ALLUPPERCAPSISNOTBETTERBECAUSEITFEELSLIKESOMEONEISSCREAMINGATME.

CamelCaseIsMarginallyBetterButItStillTakesTimeToParse.    

i_recommend_sticking_with_lower_case_and_underscore

일반적으로 참조 된 테이블의 이름보다는 설명 된 관계와 일치하도록 "매핑 테이블"의 이름을 지정하는 것이 좋습니다. 사용자는 제품에 대한 관계의 수에는 제한이 없습니다 : user_likes_product, user_bought_product, user_wants_to_buy_product.

단수와 복수에 대해서는 '올바른'것은 없습니다. 그것은 대부분 맛의 문제입니다.

그것은 부분적으로 당신의 초점에 달려 있습니다. 테이블을 하나의 단위로 생각하면 '복수'를 보유합니다 (행이 많기 때문에 복수 이름이 적절 함). 테이블 이름을 테이블의 행을 식별하는 것으로 생각하면 '단일'을 선호합니다. 이는 SQL이 테이블의 한 행에서 작업하는 것으로 간주됨을 의미합니다. 일반적으로 지나치게 단순화되었지만 괜찮습니다. SQL은 세트에서 작동합니다 (더 많거나 적음). 그러나 우리는이 질문에 대한 답을 단수로 사용할 수 있습니다.

1. 테이블 'user', 다른 'product'및 사용자를 제품에 연결하기위한 세 번째 테이블이 필요할 것이므로 'user_product'테이블이 필요합니다.

2. 설명은 제품에 적용되므로 'product_description'을 사용합니다. 각 사용자가 각 제품의 이름을 지정하지 않는 한 ...

3. 'user_product'테이블은 제품 ID와 사용자 ID가 있고 그다지 많지 않은 테이블의 예입니다. 두 속성 테이블의 이름을 일반적인 방식으로 'user_stuff'로 지정하십시오. 'rel_'과 같은 장식 접두사는 실제로 도움이되지 않습니다. 예를 들어, 각 테이블 이름 앞에 't_'를 사용하는 사람들이 있습니다. 많은 도움이되지 않습니다.

복수형은 일관되게 사용되는 한 나쁘지 않지만 단수형이 선호됩니다.

다 대다 관계를 설명하고 싶지 않다면 밑줄을 생략합니다. ORM에서 물건을 구별하는 데 도움이되기 때문에 초기 자본을 사용하십시오.

그러나 많은 명명 규칙이 있으므로 밑줄을 사용하려면 일관성있게 수행하는 한 괜찮습니다.

그래서:

User

UserProduct (it is a users products after all)

한 명의 사용자 만 제품을 가질 수 있다면

UserProductDescription

그러나 사용자가 제품을 공유하는 경우 :

ProductDescription

다 대다 관계에 밑줄을 저장하면 다음과 같은 작업을 수행 할 수 있습니다.

UserProduct_Stuff

UserProduct와 Stuff간에 M-to-M을 형성하기 위해-다 대다의 정확한 본질은 확실하지 않습니다.

복수형보다 단수형을 사용하는 것이 더 정확하지 않습니다. 어디서 들었습니까? 차라리 데이터베이스 테이블의 이름을 지정하는 데 복수 형식이 더 일반적이라고 말하고 싶습니다. 테이블은 종종 하나 이상의 행을 포함합니다.) 개념 모델에서 엔티티의 이름은 종종 단수입니다.

귀하의 질문에 대해 'Product'와 'ProductDescription'이 모델의 ID (즉, 엔티티)가있는 개념이라면 간단히 'Products'및 'ProductDescriptions'테이블을 호출합니다. 다 대 다 관계를 구현하기 위해 사용되는 테이블의 경우 "Student2Course"와 같은 이름 지정 규칙 "SideA2SideB"를 가장 자주 사용합니다.