우리 프로젝트는 복잡한 관계가있는 ~ 40 개의 테이블을 가지고 있습니다. 동료는 제가 모듈 외부의 테이블에 대해 배우도록 강요하는 긴 조인 쿼리를 사용한다고 생각하지만 제 모듈에 직접 관련되지 않은 테이블과 데이터 액세스를 신경 쓰지 않아야한다고 생각합니다 함수 (다른 모듈을 담당하는 사람이 작성)를 사용할 수 있습니다. 고객에게 공급 업체에 문의하고 특정 제품에 대한 대화를 시작할 수 있도록 해주는 ContactVendor 모듈에 대한 책임은 사용자에게 있습니다. 제품 모듈은 자체 테이블을 가지고 있으며 세부 정보 (예 : i18n, 활성화, 제품 가용성 등)를 캡슐화하는 기능과의 관계가 있습니다. 이제는 공급 업체와 고객 간의 대화와 관련된 일부 제품의 제품 제목을 표시해야합니다. (제품 테이블에 대해 배울 수있는) 한 번에 대화 내용과 함께 제품 정보를 검색하는 긴 쿼리를 작성하거나 관련 product_id를 get_product_info (int) 함수에 전달할 수 있습니다.복합 JOIN이 높은 결합 및 유지 보수 문제를 유발합니까?
첫 번째 접근 방식은 분명히 요구 사항이 많으며 프로그래밍에서 잘못 생각한 많은 나쁜 습관과 것들을 소개합니다. 루프가 개별 쿼리를 수행하는 함수를 사용하여 100 개의 제품에 대해 제품 제목을 가져 오려고 할 때 두 번째 접근법의 문제점은 이러한 액세스 함수가 야기하는 수많은 미니 쿼리 인 것처럼 보이며 성능 손실이 우려됩니다. 그래서 "구현 코드, 인터페이스 코드"와 성능 사이에 붙어 있습니다. 어떤 일을하는 올바른 방법은 무엇입니까?
업데이트 : 특별히 모듈 외부의 테이블에 대한 향후 수정 가능성에 대해 우려하고 있습니다. 제품 모듈이 일을하는 방식을 변경하기로 결정했다면 어떨까요? 또는 어떤 이유로 스키마를 수정합니까? 그것은 변경 사항이 통합 될 때까지 다른 모듈이 고장 나거나 고장날 수 있음을 의미합니다. 일반적인 파급 효과 문제.
제품 모듈이 스키마를 수정하기로 결정한 경우 어떻게됩니까? 결과 리플 효과가 많은 모듈을 파괴하지 않을까요? 반면, 다른 모든 모듈이 제품 모듈이 제공하는 인터페이스를 사용하여 제품에 액세스하는 경우 아무 것도 잘못 될 수 없습니다. (희망! ;-)) –
@ ashkan.kh : 내 응답이 너무 길어서 추가했습니다. 대답에서. – MJB