외래 키 필드 기반 변경

SQL (특히 mysql)에서는 type이라는 열거 형 (이름, 관계)과 idtype이라는 int가있는 테이블을 고려해야합니다.외래 키 필드 기반 변경

그런 다음 idname 필드가있는 다른 테이블과 idrelation 필드가있는 다른 테이블이 있습니다.

본질적으로 type == name 인 경우 idtype은 idname의 외래 키이고 type = relation 인 경우 idtype은 idrelation의 외래 키입니다. 그런 외래 키 관계를 지정하는 방법이 있습니까? 또는/그리고 mysql에서 그러한 관계를 표현하는 더 나은 기존의 방법이 있습니까?

감사합니다, 데이비드

출처

2011-08-25 David Mokon Bond

언제든지 이런 식으로하고 싶다면 데이터베이스 디자인에 치명적인 결함이 있다는 신호입니다. – HLGEM

문제는 당신이 하나의 테이블에있는 정보의 두 differen 종류를 저장하고 있다는 것입니다 - 거의 항상 나쁜 생각 (IMO)을. 첫 번째 테이블을 두 개로 나누어야합니다. 또 다른 옵션은 nameID 및 typeID라는 두 개의 필드를 갖는 것입니다. 그러나 그렇게하는 것은 좋지 않습니다. 귀하의 테이블에 대한 자세한 내용이 없으면보다 구체적인 답변을 드릴 수 없습니다.

출처

2011-08-25 18:00:02

저는 대개 객체 지향 구문에서 상속과 비슷한 것으로 이것을 모델링합니다.

Products 
    id (PK) 

Widgets 
    product_id (FK to Products.id) (PK) 
    <widget specific columns> 

Whatsits 
    product_id (FK to Products.id) (PK) 

Product_Types 
    type_id 
    product_id (FK to Products.id)

그런 식으로 제품 유형을 제품 하위 유형과 연관시킬 수 있습니다.

당신의 디자인은 조금 "느슨한 거위"로 들리지만 어쩌면 그저 당신이 예제를 보여주고 있기 때문일 것입니다. 나는 EAV 모델에 대해서 알아내는 것이 좋을 것이다. 당신이 그 패턴을 사용하고 있는지 아닌지를 말할 수는 없지만, 아마도 당신처럼 보입니다.

출처

2011-08-25 18:01:00

나에게도 EAV처럼 들렸다. 대부분의 경우 데이터를 저장할 수있는 최악의 방법. – HLGEM

이것은 실제 또는 일반적인 사용자로드에서는 잘 작동하지 않는 디자인처럼 들립니다. 정말로 EAV 테이블이 매우 열악한 설계 선택 인 이유를 정말로 읽어야합니다. EAV의 유연성은 길고 복잡하며 끔찍한 쿼리를 작성하고 성능이 심각하게 저하 될 수 있음을 감안할 때 매우 높은 비용으로 구입할 수 있습니다. EAV는 클라이언트별로 매우 사용자 정의가 매우 드문 경우에만 사용해야합니다. 그러나 디자인에서 올바르게 작업 한 경우 95 % 이상을 관계형으로 모델링해야합니다.

그러나 진정으로 이러한 문제에 빠지면 진정한 FK 관계를 실행할 수있는 유일한 방법은 트리거를 사용하는 것입니다. 그들을 강요하지 않으면 더 나쁜 생각이며 손상된 데이터로 이어질 것입니다.

출처

2011-08-25 18:09:18 HLGEM

외래 키 필드 기반 변경

답변

관련 문제