Les utilisateurs connectés peuvent vérifier à tout moment le nombre de nouveaux contrats sur une certaine période
华东区总经理
|--- 华东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 修改人
【新增合同数】 = 【所有下级的新增合同数】+【本人新增合同数】
La base de données est MySQL, car le nombre de contrats supérieurs est la somme du nombre de contrats de tous les subordonnés, nous obtenons donc récursivement les identifiants utilisateur de tous les subordonnés de l'utilisateur
puis utilisons count(*) de table où (conditions de la période créée_à) et créé_par dans (tous les ID utilisateur subordonnés, y compris l'ID utilisateur actuellement connecté)
Problème : Les données sont exactes, mais inefficaces et ont un impact sur les performances du serveur
Utilisez un tableau séparé pour enregistrer chaque jour le nombre de nouveaux contrats pour chaque utilisateur, ou obtenez d'abord les identifiants de tous les utilisateurs subordonnés, puis utilisez
select sum (inum) from user_count Where (created_at time period condition)
et create_by in (tous les ID d'utilisateur subordonné, y compris l'ID d'utilisateur actuellement connecté)
Problème : ce champ doit être modifié à chaque fois que vous ajoutez, supprimez ou supprimez par lots. Si le nombre d'utilisateurs augmente, la possibilité de compter les erreurs est très élevée. Bien que les statistiques soient pratiques, les données sont inexactes.
Notre site Web comptera les nouveaux ajouts d'aujourd'hui, les ajouts d'hier, les ajouts de cette semaine, les ajouts de ce mois, les ajouts de ce trimestre et les ajouts de cette année. Les utilisateurs peuvent également saisir leur propre période pour interroger
Avez-vous des suggestions. ? Une solution qui peut rendre les données à la fois précises et statistiquement efficaces ?
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Pensez à mettre une copie du contrat nouvellement ajouté dans Redis et à l'effacer une fois par jour.
L'option 1 est l'option privilégiée. Le seul problème est qu'elle est lente à obtenir de manière récursive tout le personnel subordonné. Alors résolvons ce problème !
Supposons que la structure approximative de la table du personnel soit la suivante, un stockage de données arborescent typique.
ID, Nom, ParentId
Ajoutez-y un champ Chemin, dont la valeur est le chemin d'accès à la personne, tel que
-12-45-765-, où 765 est l'ID utilisateur actuel, 45 est le supérieur de 765 et 12 est le supérieur de 45.Avec ce champ, il est facile de filtrer tous les subordonnés d'un leader et lui-même en fonction de son identifiant.
select id from employee where path like '%-45-%'N'oubliez pas de mettre à jour ce champ lors de la mise à jour future des affiliations du personnel.
Si vous disposez d'une grande quantité de données, vous devez les interroger et les calculer à chaque fois que vous les consultez. C'est très, très stressant, quelle que soit la solution que vous utilisez.
Pour ce genre de chose, autant faire du streaming directement des statistiques de calcul. Calculez une donnée une fois et interrogez-la directement lorsque vous l'utilisez.
Afin de ne pas affecter les performances des processus normaux, les statistiques informatiques en streaming peuvent être exploitées de manière asynchrone
Notre système a réalisé des statistiques similaires. Vous pouvez voir les 90 derniers jours en consultant les statistiques quotidiennes et les 3 dernières années. en regardant les statistiques mensuelles, auparavant, vous ne pouviez les visualiser que par année, ce qui semble être similaire à vos besoins
J'ai écrit un petit code pour le calcul des statistiques de flux, ce qui prenait moins d'une semaine.
github.com/panjjo/flysnow Bien sûr, l'écriture du code est assez mauvaise.
Il s'agit d'une exigence OLAP courante dans le domaine des bases de données, et des vues matérialisées peuvent être prises en compte.
Pour référence.
J'adore MongoDB ! Amusez-vous!
Écrire un timer résoudra le problème, c'est tout ! ! !