비슷한 디자인의 두 필드가있는 데이터베이스 디자인의 욕망

Question

좋아, 이제는 "상자 항목"에 대한 표를 만들고 있습니다.

이제 상자 항목은 항목의 상태/용도에 따라 "배송"상자 또는 "반품"상자와 관련이 있습니다.

상자 항목에 결함이있을 수 있음 : 상자 항목의 행 (IsDefective)에 플래그가 설정되고 상자 항목이 "반환"상자에 표시됩니다 (다른 항목은 해당 공급 업체). 그렇지 않으면 상자 항목은 결국 "배송"상자에 넣어집니다 (다른 항목도 함께 제공됩니다). (배송 및 반품 상자에는 자체 테이블이 있습니다. 모든 상자에 공통된 테이블이 하나도 없습니다. 가능하면 3 번째 가능성을 고려해야합니다.)

어쩌면 나는 분명히 생각하고 있지 않을 수도 있습니다. 오늘 나는이 상황에서해야 할 일을 묻기 시작했다.

BoxItemID :

내 직감은 내가 박스 항목에 대한 스키마를 만들 것 주어진 시간에 일어날 수있는 관계, 단 하나의 모양을 경우에도 가능한 각 관계에 대해 별도의 필드가 있어야 하더군요 설명 IsDefective 는 이는 관계가 명확하게,하지만 그것 (하나의 관계의 이후 언제든지 사용) 낭비 보인다 등 ...

을 ReturnBoxID ShippingBoxID.

BoxItemID 설명 IsDefective BoxID 등 : 그럼 본인은 BoxID에 대한 하나 개의 필드가, 그것이 (A 배송 또는 반환 박스 ID)를 IsDefective 필드를 기준으로 참조 것 BoxID 결정할 수 있다고 생각 ..

이것은 덜 낭비되는 것처럼 보이지만 나와 함께 앉아 있지 않습니다. 그 관계는 분명하지 않습니다.

그래서 저는 여러분에게 Stackoverflow의 데이터베이스 전문가를 소개합니다. 이 상황에서 당신은 무엇을 할 것입니까?

편집 : 입력 해 주셔서 감사합니다. 생각할 시간이 많이 주어졌습니다. 하나는 다음에이 프로젝트를 시작할 때 ORM을 사용할 것입니다. =) 2의 경우, 지금 당장은 아니기 때문에 4 바이트를 물어보고 두 개의 필드를 사용합니다.

다시 한 번 감사드립니다.

Answer 1

나는 Psychotic Venom과 mattlant입니다.

다형성 경로 (다른 필드의 내용을 기반으로 외래 키가 가리키는 테이블을 찾아야 함)로가는 것은 고통이 될 것입니다. 그 제약 조건을 코딩하는 것은 힘들 수 있습니다. (대부분의 데이터베이스가 네이티브로 지원할 지 확신하지 못합니다. 트리거를 사용해야 할 것입니다).

항목이 테이블 사이를 이동할 수 있습니까? 하나는 반품을위한 것이고 다른 하나는 운송을위한 것 인 동일한 정의가있는 두 개의 테이블을 사용하는 것이 가장 쉬운 방법 일 수 있습니다. 두 개의 개별 필드를 사용하여 처음 제안한 정의를 계속 사용하려면 완벽하게 합리적입니다.

"조기 최적화는 모든 악의 뿌리"라는 것입니다. 낭비되는 동안, 당신이 저장하고있는 것을 기억하십시오. 그들은 ID이기 때문에 아마도 정수 일 것입니다. 아마도 4 바이트 일 것입니다. 레코드 당 4 바이트를 낭비하는 것은 기본적으로 아무것도 아닙니다. 사실 주소 나 다른 것들을 넣기 위해 패딩을하기 때문에 거기에 여분의 필드를 넣는 것이 "자유"일 수 있습니다. 그것은 모두 DB 디자인에 달려 있습니다.

다형성 경로를 사용해야하는 아주 좋은 이유가 없다면 (예 : 메모리가 거의없는 임베디드 시스템에 있거나 아주 느린 9600bps 링크를 통해 복제해야하는 것처럼) 두통이있을만한 가치가 없을 것입니다. 결국 끝날 수 있습니다. 모든 특수 사례를 쿼리에 작성해야 성가신 수 있습니다.

간단한 예 : 가입하려는 경우 isDefective 플래그가 설정되어있는 경우 두 테이블간에 조인을 수행하면 문제가 발생합니다. 두 컬럼 중 하나만 사용하는 것이 적어도 나를 위해 절약 할 수있는 번거 로움 일 수 있습니다.

Answer 2

당신이 말하는 것은 다형성 관계입니다. 다른 여러 테이블을 참조 할 수있는 단일 ID입니다. 그러나이를 지원하는 여러 프레임 워크가 있지만 데이터베이스 무결성 (데이터베이스 또는 응용 프로그램이 참조 무결성을 유지해야하는지 여부와 상관없이 전체적으로 다른 토론이 될 수 있음)에 잠재적으로 좋지 않습니다.

어떨까요?

BoxItem: 
BoxItemID, Description, IsDefective 

Box: 
BoxID, Description 

BoxItemMap: 
BoxID, BoxItemID, BoxItemType 

그럼 당신은 당신이 "반환"또는 상자의 유형으로 "배송"등의 응용 프로그램에서 상수를 정의 곳 BoxItemType가 열거, 또는 정수가 될 수 있습니다.

Answer 3

상자에 대해 하나의 테이블을 만들고 상자 유형을 상자 테이블의 열로 만드는 것을 고려할 것입니다. 이렇게하면 관계를 단순화하고 상자 유형을 계속 쿼리 할 수 ​​있습니다. 따라서 상자 항목에는 boxId에 대한 하나의 외래 키만 있습니다.

Answer 4

위의 다형성 논의에 대해 동의하지만, 사용 빈도가 낮지 만 여전히 실용적인 솔루션입니다.

기본적으로 상자라는 기본 테이블이 있습니다. 그런 다음 두 개의 다른 테이블, 배송 상자 및 반환 상자가 있습니다. 이 두 가지는 특별한 필드를 추가합니다. 그들은 1 : 1 fk.Boz 기본 표가있는 상자와 관련이 있습니다. 모든 상자 유형의 공통 필드가 있습니다.

BoxItem은 박스 테이블과 관련이 있습니다. 적절한 상자 유형을 얻는 방법은 하위 상자를 키를 기반으로 루트 상자로 조인하는 쿼리를 수행하는 것입니다. 기본 상자와 자식 상자 모두에있는 레코드는 해당 형식입니다.

제대로 완료된 상자 유형을 만들 때주의해야합니다. 테스트는 무엇을위한 것입니다. 그것들을 추가하는 코드는 한 번만 작성해야합니다. 또는 ORM을 사용하십시오.

거의 모든 ORM이이 전략을 지원합니다.

Answer 5

아마로 갈 것 :

BoxTable: 
box_id, box_descrip, box_status_id ... 
    1, Lovely Box, 1 
    2, Borked box, 2 
    3, Ugly Box, 3 
    4, Flammable Box, 4 

     BoxStatus: 
     box_status_id, box_status_name, box_type_id, .... 
        1,Shippable, 1 
        2,Return, 2 
        3,Ugly, 2 
        4,Dangerous,3 

       BoxType: 
       box_type_id, box_type_name, ... 
          1, Shipping box, ... 
          2, Return box, .... 
          3, Hazmat box, ... 

박스 상태는 상자 유형을 정의하는 방법을, 당신이 나중에 몇 가지 더 상태 수준 또는 상자 유형으로 확장해야하는 경우가 유연.

Answer 6

IsDefective, ShippingBoxID, 배송 상자 관련 필드, ReturnBoxID 및 반환 상자 관련 필드가 포함 된 하나의 BoxItems 테이블 만 있으면됩니다. 일부 필드는 각 레코드마다 항상 NULL입니다.

이것은 매우 간단하고 자명 한 디자인으로 다음 개발자가 혼동하지 않을 것입니다. 이론적으로이 디자인은 각 행에 대해 보장 된 빈 필드 때문에 비효율적입니다.실제로 데이터베이스는 어쨌든 각 행마다 필요한 최소 저장소 크기를 갖는 경향이 있으므로 (필드 수가 많지 않는 한)이 디자인은 가능한 한 효율적이고 코드 작성이 훨씬 쉽습니다.

Answer 7

내가 Hibernate는 Table-per-subclass를 부르는 것을 사용하는 거라고, 그래서 내 DB는 박스에 대한 3 개 테이블과 바람 것 : Box, ShippingBox 및 ReturnBox. BoxItem의 FK는 Box을 가리 킵니다.