登陆用户可以随时查看某个时间段的新增合同数
华东区总经理
|--- 华东1区经理
| |---销售主管11
| | |---销售员111
| | |---销售员112
| |---销售主管12
| |---销售员121
| |---销售员122
|
|
|--- 华东2区经理
|---销售主管21
| |---销售员211
| |---销售员212
|---销售主管22
| |---销售员221
| |---销售员222
|---销售主管23
| |---销售员231
| |---销售员232
华北区总经理
|--- 华北1区经理
| |---销售主管31
| | |---销售员311
| | |---销售员312
| |---销售主管32
| |---销售员321
| |---销售员322
|
|
|--- 华北2区经理
|---销售主管41
| |---销售员411
| |---销售员412
|---销售主管42
| |---销售员421
| |---销售员422
|---销售主管43
| |---销售员431
| |---销售员432
id 合同id
name 合同名称
created_at 创建时间
created_by 创建人
updated_at 修改时间
updated_by 修改人
【新增合同数】 = 【所有下级的新增合同数】+【本人新增合同数】
数据库是mysql,因为上级合同数,是所有下级的合同数之和,所以,我们递归得到了用户所有下级的用户id
然后再用count(*) from 表 where (created_at时间段条件) and created_by in (所有的下级用户id,包含当前登录用户id)
问题:数据是准确的,但是效率低下,对服务器性能也有影响
单独用一个表来记录每个用户每天的新增合同数,还是先得到所有下级用户的id,然后再用
select sum(inum) from user_count where (created_at时间段条件)
and created_by in (所有的下级用户id,包含当前登录用户id)
问题:每次 增加,删除,批量删除,都要修改这个字段,如果用户量增大,计数错误的可能性非常大,虽然统计方便了,但是数据不准确
我们网站要统计今日新增,昨日新增,本周新增,本月新增,本季度新增,本年新增,用户还可以自己输入时间段查询
请问大家有没有什么好的方案,可以让数据既准确,统计起来效率又高的?
新しく追加したコントラクトのコピーを Redis に置き、1 日 1 回クリアすることを検討してください。
オプション 1 が推奨されます。唯一の問題は、すべての部下の人材を再帰的に取得するのに時間がかかることです。それでは、この問題を解決してみましょう!
人事テーブルは次のようなおおよその構造 (典型的なツリー状のデータ ストレージ) を持っていると仮定します。
ID、名前、親ID
Path フィールドを追加します。その値は、
-12-45-765-
などの個人へのアクセス パスです。765 は現在のユーザー ID、45 は 765 の上位です。そして 12 は 45 よりも優れています。-12-45-765-
,其中765是当前用户Id,45是765的上级,12是45的上级。有了这个字段后,根据某个领导的id筛选出他所有的下级以及他自己就易如反掌。
このフィールドを使用すると、リーダーのすべての部下とリーダー自身を ID に基づいて簡単にフィルタリングできます。select id from employee where path like '%-45-%'
パスが '%-45-%' のような従業員から ID を選択
大量のデータがある場合、どのソリューションを使用する場合でも、データを確認するたびにクエリを実行して計算する必要があります。これは非常にストレスがかかります。
この種の場合は、ストリーミング計算統計を直接実行した方がよいでしょう。データを一度計算し、使用するときに直接クエリします。
通常のプロセスのパフォーマンスに影響を与えないように、ストリーミング コンピューティング統計は非同期で操作できます。
私たちのシステムでは、日次統計を見ると過去 90 日間、月次統計を見ると過去 3 年間を確認できます。 3 年前の統計のみを年ごとに表示できます。これは、ストリーム計算統計の小さなコードを書きましたが、1 週間もかかりませんでした。
github.com/panjjo/flysnow もちろん、コードの書き方はまだかなり悪いです。
これはデータベース分野における一般的な OLAP 要件であり、マテリアライズド ビューを考慮することができます。
ご参考までに。
MongoDB が大好きです!楽しむ!
タイマーを書くことで問題は解決します、それだけです! ! !