점원 관리 시스템이 있습니다. 점원은 회원을 대표하는 1W를 가지고 있습니다. 점원은 추천 메커니즘을 가지고 있습니다(점원은 거의 무제한 수준으로 추천할 수 있습니다).
점원의 판매 실적 테이블인 member_sales도 있습니다. 점원이 판매를 할 때마다 데이터가 member_sales에 기록됩니다.
이제 나는 사무원과 그의 모든 하위 사무원의 일일 매출액을 매일 계산해야 합니다. 그가 내 성과 요구 사항을 충족하면 그에게 보너스를 주겠습니다.
지금은 데이터가 많지 않아서 시간당 점원 2,000명을 세려고 크론탭을 5개 오픈했는데 5시간 만에 작업이 완료됐어요.
근데 매장 직원이 많아지면 이런 멍청한 방법이 안 통할 것 같아서요.
점원 관리 시스템이 있습니다. 점원은 회원을 대표하는 1W를 가지고 있습니다. 점원은 추천 메커니즘을 가지고 있습니다(점원은 거의 무제한 수준으로 추천할 수 있습니다).
점원의 판매 실적 테이블인 member_sales도 있습니다. 점원이 판매를 할 때마다 데이터가 member_sales에 기록됩니다.
이제 나는 사무원과 그의 모든 하위 사무원의 일일 매출액을 매일 계산해야 합니다. 그가 내 성과 요구 사항을 충족하면 그에게 보너스를 주겠습니다.
지금은 데이터가 많지 않습니다. 매 시간마다 점원 2,000명을 세려고 크론탭을 5개 열어서 5시간 만에 작업이 완료되었습니다.
근데 매장 직원이 많아지면 이런 어리석은 방법이 더 이상 통하지 않을 것 같아 걱정이에요.
데이터베이스를 사용하면 mysql은 충분히 간단합니다
데이터베이스를 사용하여 데이터에 대한 통계를 작성하고 나중에 데이터 분석을 수행할 수도 있습니다
매일 아침 이른 아침에 한 번씩만 달리면 됩니다.
데이터베이스를 사용하시나요? sql
시간당 쿼리가 2,000개만 있을 수는 없습니다. crontab
어떤 작업을 수행하나요?
이 정도 크기의 관계형 데이터베이스는 완벽합니다
계산 중인 SQL에 문제가 있는 것 같습니다. 루프 선택이 포함되어 있나요?
다시 해 보세요. 사무원의 트리 구조 설계에 문제가 있었고, 통계 논리도 잘못되어 너무 오래 걸리고 수십 문장으로 설명할 수 없었습니다.
점원은 트리 구조를 가져야 하며, 그의 판매 실적은 그 자신과 그의 모든 하위 노드의 판매 실적의 합입니다.
또한 member_sales 테이블에는 판매 날짜와 판매 시간이라는 두 개의 필드가 있어야 합니다. 판매 날짜는 통계에 사용되며 판매 시간 형식으로 날짜를 변환할 수 없습니다.
트리 구조는 무제한의 카테고리를 참조할 수 있습니다.
예정된 작업에 대한 모든 SQL과 프로그램을 게시하고 살펴보세요