일대일 부울 관계 정규화

Question

큰 테이블 products가 있습니다. 내 제품 모델에 부울 플래그 disabled을 추가해야합니다. 일반적으로 기존 테이블에 새 필드를 추가합니다. 그러나이 속성은 거의 사용되지 않고 테이블의 레코드 수를 감안할 때이 새로운 필드는 성능 및 디스크 공간에서 불필요한 히트를 만듭니다.

그래서 일대일 관계에 대해 일종의 1NF 정규화를 수행하기로했습니다 (즉이 필드를 외래 키가있는 다른 테이블로 이동하면 products), 이것이 실제로 1NF인지는 알 수 없습니다. 내 질문). 그러나 각 제품의 disabled 속성에 실제로 true 및 false 값이 필요하지는 않습니다. 이는 관계의 테이블 크기가 products 크기와 같기 때문입니다. 따라서 관계 테이블의 값 필드에는 필요가 없습니다. 따라서 내 스키마는

CREATE TABLE products (
    id INT PRIMARY KEY, 
    name VARCHAR 
); 

CREATE TABLE disabled_products (
    product_id INT NOT NULL, 
    CONSTRAINT fk_product FOREIGN KEY (product_id) REFERENCES products (id) ON DELETE CASCADE 
); 

(SQLFiddle to fiddle around)입니다.

따라서 내가 원하는 것을 정확하게 수신합니다. 값은 플래그가 설정된 드문 경우에만 저장됩니다. 뒤에서 플래그는 테이블 열이 아닌 주어진 제품에 대한 레코드가 매우 존재하여 disabled_products으로 표시됩니다.

내가 올바르게하고 있는지 알고 싶습니다.

그러한 디자인의 단점은 무엇입니까?

관계형 모델에 적합합니까 (에 의해이 일반화 된 방식과 일반적으로 단일 외래 키 열로 구성된 테이블을 의미 함)? 그렇다면 RDB 과학의 관점에서이 솔루션을 어떻게 부릅니까?

Answer 1

사람들은 종종 테이블을 분할해야하는지 또는 하나의 큰 테이블을 작성해야하는지 스스로 자문합니다. 나는 바닥에있는 일반적인 논리에 대해 이야기 할 것입니다. 귀하의 경우에 그것은 순수하게 잘 정의 된 성능 계산입니다. 솔루션의

프로 & 단점 1) CON : 기록이 거의 불가능하지 않습니다 비록 당신이 활동 기록을 필요로 모든 쿼리에이 테이블을 가입 LEFT해야합니다.

2) CON : 공간 절약 효과는 무시할 수있는 1 바이트이므로 무시해야합니다.

3) PRO : 문제가 될 수있는 테이블을 변경하지 않아도됩니다.

권장 사항 : 위의 장단점을 감안할 때 테이블에 필드를 추가하는 것이 좋습니다. 그것은 단지 하나의 바이트입니다.

일반적으로 테이블을 수정하거나 특정 필드 집합이 필요한 레코드 클래스가 다른 경우 또는 성능상의 이유로 테이블을 분할하려는 경우 테이블을 세로로 분할합니다.

Answer 2

가능한 단점은 분명합니다. 열 값으로 저장하는 것과는 달리 모든 행에 disabled 값이 있다고 가정 할 수 없으므로 (사용자 정의 논리를 적용해야 함) 두 테이블을 내부 조인 할 수 없습니다. 테이블을 작게 설정하면 결과가 크게 줄어 듭니다. 또한 추가 테이블은 중요한 정보를 포함하지 않고 비활성화 상태를 나타내므로 완전히 중복됩니다. "성능에 유리한 중복성"에 대해서는 별 모양 (http://en.wikipedia.org/wiki/Star_schema)을 떠올리게됩니다.