마술 테이블을 통한 관계

Question

흥미로운 SQL 테이블 (나열된 열 이름)이 있습니다 :
From_TableName | From_Id | To_TableName | To_Id

내가 이해 한 바로는,이 테이블은 데이터베이스의 모든 테이블 관계에 사용됩니다. 데이터베이스에는 많은 데이터 (앞에서 언급 한 표에 10000 개가 넘는 행)가 없으므로 성능이 그렇게 중요하지는 않습니다. 저는 SQL 전문가가 아니므로 여기서 질문하기로 결정했습니다. 이것을 DailyWTF에 보내야합니까, 아니면 어떤 상황에서 이것이 가능한 솔루션입니까?

내 생각 : 나는이 접근법으로는 어떤 단점도 보지 못했다. 물론 모든 관계에 대해 하나의 테이블 만 있으면되지만 그다지 플러스는 아닙니다. 새 테이블을 만들 때 실제로 작업량이 적을 지 확신하지 못합니다. 사용자가 무엇이든 할 수있게하려는 경우가 아니라면 어떤 종류의 유효성 검사 로직이 있어야합니다 (어떤 종류의 관계가 유효합니까?) 어딘가에 업데이트해야합니다.

Answer 1

이것은 응용 프로그램 계층 (잘하면)의 엔티티 형 개체 매핑에 사용되었을 뿐이며 sql 데이터베이스 자체에서는 사용되지 않았을 가능성이 큽니다.

비록 권장되지는 않지만 이전에 이러한 접근법을 보았습니다.

이것은 심각한 성능 문제를 일으킬 수 있지만, 말했듯이 데이터베이스는 매우 작습니다.

나는 이것이 완전히 변론했다고 생각하지 않는다. DailyWTF.

Answer 2

사용자 정의 ORM과 같은 디자인을 보았습니다. 경우

이 의미가 있습니다 :

이

• "테이블 이름" "클래스 이름"
• 모든 클래스 인스턴스는
• 실제 테이블이 클래스 속성을 포함하는 별도의 테이블에 저장됩니다로 읽

Answer 3

개발자가 개입하지 않아도 언제든지 사용자가 새로운 테이블과 관계를 추가 할 수있는 시스템에서 작업했습니다.

Answer 4

별도의 테이블을 사용하여 관계형 정보를 포함하는 방식은 그다지 드문 것이 아닙니다. 많은 프레임 워크 (예를 들어 Rails)는이를 사용하여 다 대 다 관계를 저장합니다. 그러나 이러한 경우 일반적으로 관계 당 하나의 테이블이며 두 테이블의 ID 만 테이블에 있습니다.

이전에이 접근법을 보지 못했습니다. 각 관계에 대해 별도의 테이블을 갖는 대신 모든 관계가 하나로 수집됩니다. 방금 설명한 접근 방식에 비해이 접근 방식의 유일한 단점은 성능입니다. 테이블이 적어서 데이터베이스의 혼란이 줄어 듭니다 (일부 경우 어쨌든).

아니요, 분명히 DailyWTF에 합당하지 않습니다. 디자인에 대해서는 의문을 제기했지만 비웃는 것은 아닙니다.