웹 응용 프로그램 프로젝트를위한 데이터베이스를 설계하고 있는데 한 번만 확인하기 위해 많은 조인 된 테이블을 필요로하는 쿼리가 거의 없을 수 있습니다.조인을 피하기 위해 "중복"외래 키 저장
이러한 쿼리에 필요한 조인 수를 줄이기 위해 외래 키를 저장하는 것이 얼마나 좋지 않을까요?
당신에게 나는이 순간에 무슨의 예를 제공합니다 : 서비스 => 예약 => 거래 => 지갑 => BonusOffer
나는 서비스가와 관련된 지갑 구입되었는지 여부를 확인해야합니다 보너스. BonusOffer id를 Transaction의 외래 키로 저장하는 것이 현명한 방법일까요?
당신은 왜 이러한 거래가 "거래를 통과 할 것인가"라는 질문을 던질 수 있습니다. 거래와 거래는 중간에있을 것입니다.
관계형 DBMS가 작동하는 방식입니다. 정규화에 대해 배우고 사용하십시오.
서비스가 보너스와 연결된 지갑으로 구매되었는지 여부를 확인해야합니다.
모든 서비스에 해당되는 경우 데이터베이스에 제약 조건이 적용됩니다. (select service from Service_has_transaction join Transaction_has_wallet)은 (select service from Service_has_transaction join Transaction_has_wallet join Wallet_has_bonus)의 하위 집합입니다.
대부분의 SQL DBMS는 해당 제약 조건을 선언적으로 표현할 수 없으며이를 강제 적용하는 방법을 알지 못합니다. 그러나 &을 표현하는 데 사용할 수있는 SQL 관용구가 선언적으로 시행합니다. 테이블 정의에서 추측 :) 먼저 bonus 열을 Transaction_has_wallet에, 외래 키를 Transaction_has_wallet (wallet, bonus)에서 Wallet_has_bonus으로 추가합니다. 그런 다음 Service_has_transaction에 지갑 & 보너스 칼럼을 추가하고 Service_has_transaction (transaction, wallet, bonus)에서 Transaction까지 외래 키를 추가하십시오. 이는 여분의 열을 추가하지만 그럼에도 불구하고 외부 키 제약 조건이 중복 값이 잘못되지 않도록 데이터베이스를 유효한 상태로 제한합니다. (희망적으로 이것은 트리거를 통해 임의의 제약 조건을 표현하는 것에 대해 배우기위한 모범 사례입니다.)
내 마음은 당신이 shouldnt한다고 말하지만, 내 마음은 당신이 원한다면 시도 할 수 있다고 말합니다. 언제든지'EXPLAIN PLAN'을 점검하여 개선이 있는지 확인하십시오. 언젠가 당신은 무언가를 최적화하려고 많은 시간을 소비하기 때문에 db가 이미 최적화되도록 설계되었으므로'너무 많은'에 대해 걱정할 필요가 없습니다. –
@JuanCarlosOropeza가 내 마음을 움직입니다! 저는 헬퍼 테이블을 사용하여'BonusOffer'와'Transaction' 사이를 연결하는 방법을 생각했습니다. 이 방법을 사용하면 중복성을 피할 수 있으며 쿼리가 만족 스럽습니다. 그게 더 나은 방법이라고 생각하니? 사실 이러한 쿼리는 어쨌든 빠를 것이라고 확신하지만 실제로 성능 문제가 발생하면 성능을 위해 데이터베이스를 최적화하기 전에 자세한 정보를 얻고 싶습니다. – user1970395
나는 더 나은 방법이라고 생각하지 않는다. 왜냐하면 이상은 무언가를 복잡하게하고 정상 이상이 될 것이기 때문이다. 그 의미는 암울하기가 더 어려울 것이며, 당신은 당신의 영리한 지름길에 대해 당신 뒤에 오는 모든 사람들에게 설명 할 필요가 있습니다. –