2011-01-25 4 views
4

이 질문은 일반적인 질문이지만 이전 질문 목록에서 찾을 수 없습니다. 기본 키 인덱스를 공유해야하는 제품에 대한 테이블 집합이 있습니다. 다음과 같이 가정하십시오.공유 기본 키

product1_table: 
    id, 
    name, 
    category, 
    ...other fields 

product2_table: 
    id, 
    name, 
    category, 
    ...other fields 

product_to_category_table: 
    product_id, 
    category_id 

분명히 두 제품 테이블간에 공유 색인을 갖는 것이 유용 할 것입니다. 참고로, 그것들을 분리하여 보관한다는 아이디어는 기본을 뛰어 넘는 필드가 크게 다르기 때문에 공통된 분류를 공유합니다.

UPDATE :

많은 사람들이 제안 테이블 상속 (또는 발전기 사양). 이것은 알고있는 옵션이지만 다른 데이터베이스 시스템에서는 MySQL과 비슷한 솔루션을 원했던 테이블간에 시퀀스를 공유 할 수 있습니다. 나는 그것이 응답에 근거하지 않는다고 가정 할 것이다. 나는 상속에 가야 할 것 같아요. 고마워요.

+0

는 MySQL은 시퀀스 또는 일련 번호 열이 있습니까? –

+0

예, 기본 키의 일반적인 방법은'auto_increment' 정수 컬럼입니다. – chaos

+0

Auto_increment 열은 START 또는 STEP과 같은 매개 변수를 허용합니까? –

답변

8

정말 일반적인 것이 아닙니다. 기본 키를 공유 할 기본 방법이 없습니다.

입니다
product_table 
    id 
    name 
    category 
    general_fields... 

product_type1_table: 
    id 
    product_id 
    product_type1_fields... 

product_type2_table: 
    id 
    product_id 
    product_type2_fields... 

product_to_category_table: 
    product_id 
    category_id 

가 외국 키 유형 지정 테이블을 모든 제품에 대한 항목이 있고 유형 사이에 일반화 필드를 가지고 있으며, 하나 개의 마스터 제품 테이블이 : 내가 상황에서 할 수있는 것은 이것이다 유형별 데이터가있는 마스터 제품 테이블에 저장하십시오.

+0

그건 사실 우리가 멀리에서 벗어나려고 노력하는 이유는 다른 수준의 복잡성이 있기 때문입니다. 일반적인 분야 중 하나는 더 나은 용어를 원한다면 버전입니다. 동시에 여러 버전의 제품을 시스템에서 활성화 할 수 있습니다. – Endophage

+0

그것은 복잡하지 않습니다. 이렇게하면 훨씬 간단 해집니다. 모든 버전의 PK가 같습니까? –

+1

그게 왜 문제인지 알만한 정보가 충분하지 않습니다. 그 모든 의미는'name '대신'name, version'에 고유 한 키를 가지고 있다는 것입니다. – chaos

0

기본 키를 "공유"할 수 없습니다.

모든 세부 정보가 없어도 테이블을 단일 제품 테이블로 결합하는 것이 가장 좋습니다. 일부 제품에는 채워지고 다른 제품에는 채워지지 않는 옵션 필드가 반드시 나쁜 디자인은 아닙니다.

또 다른 옵션은 하나의 제품 테이블이있는 상속 모델과 주요 제품 테이블을 참조하고 고유 한 필드 세트가있는 두 개의 제품 "하위 유형"테이블을 갖는 것입니다. 이 모델을 쿼리하는 것은 단일 테이블 IMHO보다 더 고통 스럽습니다. 따라서이 모델을 덜 바람직한 옵션으로 간주합니다.

+0

정말 3 테이블 모델의 단점이되어서는 안됩니다. 나는 하나의 테이블과 똑같은 견해를 만들 수 있습니다. 쉬운 쿼리. 나는 정말로 반대하지 않고 단지 ' –

4

하나의 제품 표에 공통 열을 넣고 별도의 두 테이블에 특수 열을 넣는 것이 더 좋습니다. 세 개의 모든 테이블에서 product_id를 기본 키로 사용하지만, 두 개의 특수 테이블에서는 주요 제품 테이블에 다시 외래 키가 추가됩니다.

이렇게하면 범주별로 ID 및 이름에 대한 기본 제품 검색이 간단 해집니다.

또한 디자인을 통해 각 제품이 최대 하나의 카테고리에 포함될 수 있습니다.

+0

예. 단순한 1 : 1 관계. 'main'테이블에만 auto_incrementing PK가 있어야합니다. – Mchl

+0

디자인이 단일 범주를 enfoces하지 않는다고 생각합니다. 아래 내 설명을 참조하십시오. – Andrew

+0

@Andrew : 실제로 제품별로 여러 카테고리를 허용하는 테이블과 제품 이름의 단일 카테고리처럼 보입니다. 어떤 경우이든 카테고리 문제는 제품 테이블의 레이아웃에 부수적입니다. –

1

테이블 상속을 찾고있는 것 같습니다.

당신이 중 하나가 "product2" 또는 "product1"

다음 테이블 product1product2 모든 특정 속성과에 대한 참조를했을 수 제품 1과 제품 2 플러스 type 속성에 공통 속성을 가지는 공통 테이블 product를 사용할 수 있습니다 부모product.

product: 
    id, 
    name, 
    category, 
    type 

product1_table: 
    id, 
    #product_id, 
    product1_specific_fields 

product2_table: 
    id, 
    #product_id, 
    product2_specific_fields 
0

귀하의 설명은 조금 모호하지만, 내 기본적인 이해에서 나는이

제품 테이블은 일반 필드

product 
------- 
product_id 
name 
... 

product_extra1 테이블과 product_extra2 테이블을 포함 할 유혹을받을 것이다 다른 필드가 포함되어 있습니다. 이 테이블은 product.product_id와 product_extra1.product_id 사이에 적용되는 일대일 관계를 유지합니다. product_id를 설정하여 일대일 관계를 적용합니다. 외래 키 테이블 (product_extra1 등)에서 고유 제한 조건을 사용하여 고유해야합니다. 이 데이터가 교차 테이블이 무엇인지는 PRODUCT_CATEGORY 테이블 위에있는 기반으로

product_extra1 
--------------- 
product_id 
extra_field1 
extra_field2 
.... 

product_extra2 
--------------- 
product_id 
different_extra_field1 
different_extra_field2 
.... 

채워지는 방법으로 비즈니스 규칙 결정에 당신이 필요합니다 (1 많은에 - 많은 1) 것을하는 것을 의미 것 각 제품은 많은 범주와 관련 될 수 있습니다. 이것은 이제 동일하게 유지 될 수 있습니다.

1

먼저 카오스, 래리, 필이 말한 모든 것에 동의한다고 말하게하십시오. 다른 방법으로 주장하는 경우

는하지만 ...

은 공유 PK 두 가지 이유가 있습니다. 두 테이블간에 고유성이 1 개 있고 참조 무결성을 완료하는 데 2 ​​개가 필요합니다.

정확히 "시퀀스"가 Auto_increment 열 지원을 특징으로하는지 잘 모르겠습니다. 가치에 의한 증분을 정의하기 위해 system setting이있는 것처럼 보이지만 열마다 아무 것도 없습니다.

오라클에서 수행 할 작업은 두 테이블간에 동일한 순서를 공유하는 것입니다. 또 다른 기법은 auto_increment에 2의 STEP 값을 설정하고 1에서 시작하고 다른 하나는 2에서 시작하는 것입니다. 어느 쪽이든, 당신은 그들 사이에 고유 한 값을 생성합니다.

PK 열만있는 세 번째 테이블을 만들 수 있습니다. 이 열은 한 서버에서 건너 뛰는 자동 번호를 만들 방법이없는 경우 자동 번호 매기기를 제공 할 수도 있습니다. 그런 다음 각 데이터 테이블에 CRUD 트리거를 추가하십시오. 두 데이터 테이블 중 하나에 삽입하면 의사 인덱스 테이블에 삽입이 시작되고 로컬 테이블에서 사용할 ID가 반환됩니다. 마찬가지로 로컬 테이블에서 삭제하면 의사 인덱스 테이블에서 삭제가 시작됩니다. 이 의사 색인 표를 가리키는 부모를 가리켜 야하는 모든 하위 테이블.

참고 : 이것은 행 단위 트리거 일 필요가 있으며 이러한 테이블에서 느리게 진행됩니다. 그러나 "제품"과 같은 표는 처음부터 DML 비율이 매우 높지 않은 경향이 있습니다. "성능 영향"에 대해 불평하는 사람은 이 아니며 규모를 고려하면입니다.

있습니다

이는 최고의 방법이 아직 발전기 사양의 또 다른 경우입니다

+0

PostgreSQL에서도 공유 순서를 사용할 수 있지만 MySQL에는 동일한 항목이없는 것 같습니다. 또한 추악한 "다음 핵심 가치를 저장할 수있는 예비 테이블"솔루션을 피하려고합니다. – Endophage

+1

글쎄, 모든 제안을 피할 수는 없어. 어느 시점에서 너는 멍청이와 춤출거야. –

+0

그리고 공유 된 순서는 여전히 당신을 RI에 사지 않습니다. 당신은 단단한 RI를 원한다면 언제 어디서나 단일 PK가 필요할 것입니다. –