현재보고 시스템의 일부 종류를하고있다. 그림, 테이블, 그래프 모두 쿼리 결과를 기반으로합니다. 어떻게 든 복잡한 쿼리는 유지하기 쉽지 않다는 것을 알았습니다. 특히 많은 필터링이 필요한 경우 특히 그렇습니다. 이로 인해 쿼리가 매우 길고 이해하기 쉽지 않습니다. 또한 때로는 유사한 필터를 사용하는 쿼리가 실행되어 많은 중복 코드가 생성됩니다. '2010-03-10'과 '2010-03-15'사이를 선택하려고하고 위치가 'US'이고, 고객 그룹이 'ZZ'인 경우 쿼리를 만들 때마다이 조건을 다시 작성해야합니다. 이 범위에 dbms (내 경우에는 mysql)가 "범위/컨텍스트"를 지원하여 코딩 속도를 더 빠르게 유지할 수있게합니까?쿼리 지향 응용 프로그램을 유지
또한 이러한 응용 프로그램을 설계하기위한 산업 표준 또는 모범 사례가 있습니까? 내가하는 일은 데이터 마이닝이라고합니다. 맞습니까?
쿼리에서 중복 코드를 제거하는 방법을 배우십시오. http://dev.mysql.com/doc/refman/5.0/en/create-view.html
아니요, 데이터 마이닝이 아니며 일반적인 오래된보고입니다. "의사 결정 지원"이라고도합니다. 정보 기술의 빵과 버터. 궁극적으로 오래된보고를 재생하는 것이 우리가 소프트웨어를 작성하는 이유입니다. 누군가는 결정을 내리고 행동을 취하기 위해 정보가 필요합니다.
데이터 마이닝은 관계가 아직 쉽게 정의되지 않는다는 점에서 좀 더 전문화되어 있습니다. 누군가가 관계를 발견하려고 시도하기 때문에 발견 한 관계를 이용하기 위해 적절한 질의를 작성할 수 있습니다.
쿼리를 손으로 코딩하는 경우 매우 유연한보고 도구를 만들지 않습니다. 요구 사항이 바뀔 때마다 당신은 그것을 만족시키려는 꽁꽁 묶은 코드로 목에 달려 있습니다. 그런 식으로 광란이 생깁니다.
대신 쿼리 인프라 위에 메타 계층을 생각하고 사용자가 나타내는 조건에 따라 SQL을 생성해야합니다. 쿼리를 생성 할 수있는 일련의 선택 항목을 제시 할 수 있습니다. 이러한 선택을 확장 할 수 있도록하기 위해 약간의 생각을하면 이미 존재하는 많은 BI 및보고 제품의 길을 잘 따라갈 수 있습니다.
Crystal Reports (Business Objects에서 SAP를 삼킨 SAP) 또는 Eclipse의 BIRT과 같이 이미이를 수행하는 인프라를 찾고 싶을 수도 있습니다. 프로그래밍 연습이나 사용자의보고 문제 해결 방법에 따라 위에서 언급 한 것과 같이 이미 수만에 달하는 개발 기간을 거친 선반 제품을 골라 내고 싶을 수도 있습니다. Cognos (IBM이 삼킨) 또는 Hyperion (오라클이 삼켰습니다).
행운을 빈다.