대부분의 테이블에서 동일한 필드

StackOverflow https://stackoverflow.com/questions/241746

  •  04-07-2019
  •  | 
  •  

문제

데이터베이스 프로토타입에는 기능적으로 다른 여러 테이블에 필요한 필드 세트(예: 이름, 설명, 상태)가 있습니다.

이러한 필드에는 라벨링, 표시, 검색, 필터링 등에 대한 최종 사용자 기능이 항상 동일합니다.이는 외래 키 제약 조건의 일부가 아닙니다.이것을 어떻게 모델링해야 합니까?

다음과 같은 변형을 생각해 볼 수 있습니다.

  • 각 테이블은 이러한 모든 속성을 갖습니다.이 경우 이름을 어떻게 지정하시겠습니까?각 테이블에서 동일하거나 테이블 이름 접두사(예: usrName, prodName)가 있는 경우

  • 이를 속성 테이블로 이동하고 Attributes.PK를 참조하여 "핵심" 테이블에 외래 키를 추가합니다.

  • 위와 같지만 외래 키 대신 해당 코어 테이블에서도 Attributes.PK를 PK로 사용합니다.

도움이 되었습니까?

해결책

정규화라는 아이디어를 너무 멀리 가져 가고있는 것 같습니다. 당신이 당신의 중복성을 줄이고 있다는 생각입니다. 데이터. 예제는 데이터베이스 디자인의 메타 정보에서 "중복성"이 걱정된다는 것을 나타냅니다.

그러나 궁극적으로 user.name 그리고 user.description 기능은 다른 기능입니다 product.name 그리고 product.description, 그리고 그렇게 취급되어야합니다. ~을 위한 status, 그것은 당신이 의미하는 바에 달려 있습니다. ~이다 status 제품/사용자의 레코드가 활성인지 아닌지 지표입니까? 그렇다면 다른 테이블로 나누는 것이 합리적 일 수 있습니다.

"활성/만료/삭제"가 데이터베이스 내에서 상태를 표시하는 경우 제공 한 정보를 사용하면 다음과 같은 테이블 구조에 동의합니다.

users            products         status
  id               id               id
  name             name             name
  description      description
  status_id        status_id

그러나 if status 의미 적으로 다른 것을 나타내도록 선택적으로 변경 될 수 있습니다 (즉, 사용자의 경우, 아마도 "활성/은퇴/발사", 나는이를 미래의 증거로 나누는 것을 제안 할 것을 제안합니다.

user_status     product_status
  id              id
  name            name

요컨대, 데이터베이스 디자인이 아니라 데이터를 정상화하십시오.

다른 팁

동일한 이름이나 설명을 사용하지 않는 한 가치 테이블에서 해당 데이터를 정규화해서는 안됩니다. 상태 유형은 재사용되는 경향이 있으므로 정상화하십시오. 예를 들어:

order_status_types
- id
- name
- description

shipping_accounts
- id
- name
- description

orders
- order_status_type_id
- shipping_account_id

preferences
- shipping_account_id

정규화는 종종 관계형 데이터베이스에서 가장 모범 사례입니다 (이유 내).

상태와 같은 필드 (국가 내 상태를 의미)가있는 경우 (id, short_name, long_name 등)가있는 "state"와 같은 기준 테이블이 이동하는 방법 일 수 있습니다. 언급 한 바와 같이 State 테이블의 레코드에 대한 참조 인 State_id 열이 필요합니다.

그러나 어떤 경우에는 모든 데이터의 정규화가 반드시 필요하지는 않지만 반드시 필요한 것은 아니지만 어디에서 해야하는지, 어디서 수행하지 않을지는 분명해야합니다.

도움이 되었기를 바랍니다.

이름이 같고 논리적으로 유사하더라도 각 테이블에 고유한 열 집합을 제공합니다.

이러한 열 중 일부를 추가 또는 삭제하거나 데이터 유형을 변경하여 테이블 중 하나를 변경해야 하는 경우 공유 속성 테이블을 복잡하게 만드는 방법을 알아내는 대신 해당 테이블에서만 변경할 수 있습니다. .

각 테이블에 자체 속성에 대한 제어권을 부여하면 승격됩니다. 응집력, 좋은 일이네요.또한 외래 키가 어느 방향으로 가는지에 대한 질문을 피할 수 있습니다.

열 이름 지정의 경우 열 이름에 접두사를 붙일 필요도 없고 권장되지도 않습니다.두 테이블에서 같은 이름의 열이 나오는 조인을 수행하는 경우 별칭을 사용하여 구분하십시오.

나는 항상 각 테이블에 3 개의 문자 코드를 주었고 모든 필드 이름에서 사용합니다. 이런 식으로 제품 테이블에는 prdname, prddescription, prdstatus 및 공급 업체 파일에는 venname, vendescription, venstatus가 있습니다. 일이 합류되면 동일한 이름의 필드에 대해 걱정할 필요가 없습니다.

물론, 테이블에는 모두 평범한 오래된 필드가 있습니다. ID 제품 테이블에는 Venid라는 필드가있어 공급 업체 테이블의 ID 필드를 나타냅니다. 이 경우 Venid가 완벽하게 이해되고 모호하지 않기 때문에 PRD 접두사를 넣지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top