2010-06-18 2 views
0

우리 프로젝트는 복잡한 관계가있는 ~ 40 개의 테이블을 가지고 있습니다. 동료는 제가 모듈 외부의 테이블에 대해 배우도록 강요하는 긴 조인 쿼리를 사용한다고 생각하지만 제 모듈에 직접 관련되지 않은 테이블과 데이터 액세스를 신경 쓰지 않아야한다고 생각합니다 함수 (다른 모듈을 담당하는 사람이 작성)를 사용할 수 있습니다. 고객에게 공급 업체에 문의하고 특정 제품에 대한 대화를 시작할 수 있도록 해주는 ContactVendor 모듈에 대한 책임은 사용자에게 있습니다. 제품 모듈은 자체 테이블을 가지고 있으며 세부 정보 (예 : i18n, 활성화, 제품 가용성 등)를 캡슐화하는 기능과의 관계가 있습니다. 이제는 공급 업체와 고객 간의 대화와 관련된 일부 제품의 제품 제목을 표시해야합니다. (제품 테이블에 대해 배울 수있는) 한 번에 대화 내용과 함께 제품 정보를 검색하는 긴 쿼리를 작성하거나 관련 product_id를 get_product_info (int) 함수에 전달할 수 있습니다.복합 JOIN이 높은 결합 및 유지 보수 문제를 유발합니까?

첫 번째 접근 방식은 분명히 요구 사항이 많으며 프로그래밍에서 잘못 생각한 많은 나쁜 습관과 것들을 소개합니다. 루프가 개별 쿼리를 수행하는 함수를 사용하여 100 개의 제품에 대해 제품 제목을 가져 오려고 할 때 두 번째 접근법의 문제점은 이러한 액세스 함수가 ​​야기하는 수많은 미니 쿼리 인 것처럼 보이며 성능 손실이 우려됩니다. 그래서 "구현 코드, 인터페이스 코드"와 성능 사이에 붙어 있습니다. 어떤 일을하는 올바른 방법은 무엇입니까?

업데이트 : 특별히 모듈 외부의 테이블에 대한 향후 수정 가능성에 대해 우려하고 있습니다. 제품 모듈이 일을하는 방식을 변경하기로 결정했다면 어떨까요? 또는 어떤 이유로 스키마를 수정합니까? 그것은 변경 사항이 통합 될 때까지 다른 모듈이 고장 나거나 고장날 수 있음을 의미합니다. 일반적인 파급 효과 문제.

답변

0

질문의 양면을 볼 수 있습니다. 그러나 40 개의 테이블 만 있다고 가정하면, 전문 지식 영역 밖의 30 개의 테이블과 상호 작용하는 복잡성은 미미한 것처럼 보입니다. 복잡한 조인을 수행하는 쿼리 작성에 투표 할 것입니다. 결국 테이블에서 정확한 열을 아는 것 외에는 쉽게 알 수있는 것이 있습니다. 실제로 알아야 할 것은 테이블에서 사용하는 특별한 관계 나 특별한 의미입니다.

그러나 나를 위해 결정을 내릴 수있는 다른 사실은 성능 요구 사항입니다. 시스템이 현재 충분히 빠르며 하드웨어 및 테이블 크기가 각 테이블에 대한 별도의 쿼리를 사용하여 충분히 빠르지 만 모든 사람의 삶이 편한 경우 두 번째 방법을 사용하여 수행하십시오. 그러나 다른 한편으로는 사람이 속도에 대해 불평하거나 장래에 제한없이 테이블이 커질 가능성이 있거나 사용자 수가 증가 할 가능성이있는 경우 가장 좋은 희망을 갖는 방법을 사용하여 수행하십시오 더 빠르다.

답변에 대한 답변 : 반드시 그렇지는 않음. 제품 모듈에 5 개의 새로운 열이 추가되었다고합시다. 이미 이들을 사용하지 않았기 때문에 참여하지 않았거나 검색하는 방법이 무엇이든 관계없이 영향을받지 않을 것입니다. 필요로하는 방식과이를 처리하는 방법에 대한 새로운 코드를 작성해야합니다. 여하튼, 귀하가 선택한 방법으로 귀하의 측면에 대한 변경 사항이 동일하게 적용됩니다. 제품 모듈의 이름이 변경되었거나 3 열을 삭제했다고 가정 해보십시오. 그렇다면 인터페이스가 작성된 방식과 관계없이 반환 값을 처리하는 방식을 변경해야합니다. 나는 당신이 무엇을보고 있는지 알지만, 결론은 IMHO가 변경에 관련된 필드를 사용하면 코드를 변경해야한다는 것입니다. 입력란을 사용하지 않으면 입력하지 않아도됩니다. select * from tbl 쿼리를 사용하는 것과는 반대로 원하는 열만 가져 오는 경우에는 "파급 효과"가 없어야합니다.

+0

제품 모듈이 스키마를 수정하기로 결정한 경우 어떻게됩니까? 결과 리플 효과가 많은 모듈을 파괴하지 않을까요? 반면, 다른 모든 모듈이 제품 모듈이 제공하는 인터페이스를 사용하여 제품에 액세스하는 경우 아무 것도 잘못 될 수 없습니다. (희망! ;-)) –

+0

@ ashkan.kh : 내 응답이 너무 길어서 추가했습니다. 대답에서. – MJB

0

여기에서보기로 작업하는 것이 어떻습니까?

get_product_info 함수를 호출하는 대신 모든 모듈 관리자가 해당 모듈에 대한 product_info_view와 같은 뷰를 제공 한 다음 쿼리와 함께이 뷰를 사용하십시오. 이와 같이 뷰의 내부 (테이블)에 대해 고려할 필요는 없지만 데이터베이스와 엔진이 코드 및 뷰를 포함하는 최종 쿼리를 단순화하므로 성능 이점을 얻을 수 있습니다.

+0

조회수가 올바른 방법 인 것으로 보입니다. 그러나 나는 전문적인 제품에서 이러한 일들이 어떻게 이루어지는 지 알고 싶어합니다. 나는 그러한 발전의 기본 요소가 현장의 전문가들에 의해 이미 잘 조사 되어져 있었어야한다고 생각합니다. –

0

이런 종류의 일을하는 올바른 방법 (Persistence/Data Source/ORM)은 마틴 파울러 (Martin Fowler)가 그의 놀라운 저서 인 엔터 프라이즈 응용 프로그램 아키텍처의 패턴에 잘 설명되어 있습니다. 이 책은 엔터프라이즈 개발의 모든 사람들이 읽어야합니다.