Comptage comment procéder ?

[maestro1303]

Tout d'abord je suis désolé si ce post n'est pas tout à fait au bon forum(merci de m'iguiller vers le bon).
J'ai une table pour abonnés GSM sous MySQL qui contient 2 champs:
Num_Mobile et Code_Zone_Géo

(le nombre de zones est de 700 (découpage géographique ))

Cette table est renouvelée tous les jours et plusieurs cas peuvent se présenter:
1) un même mobile peut se retrouver dans toutes les éditions et être toujours dans la même zone
2)un même mobile peut se retrouver dans toutes les éditions et changer de zone
3) de nouveaux Num_Mobile peuvent apparaitre au gré des jours
4) des Num_Mobile peuvent disparaitre un moment puis réapparaitre
.....

Mon problème est de trouver le meilleur procédé de dire avec une probabilité quasi certaine que tel Num_Mobile est localisé dans telle zone(et de dire il y a été trouvé 3 fois ou 5fois ou 20 fois etc...)

Je sais qu'on peut s'y prendre de plusieurs manières de s'y prendre, quelle est la plus efficace/simple selon vous?

Merci Infiniment

[Maljuna Kris]

Saluton,

Envoyé par maestro1303

trouver le meilleur procédé de dire avec une probabilité quasi certaine que tel Num_Mobile est localisé dans telle zone(et de dire il y a été trouvé 3 fois ou 5fois ou 20 fois etc...)

A part retourner la plus haute fréquence d'apparition d'un Num_Mobile dans une zone je ne vois rien de simple, mais est-ce significatif ?
Quant à une probabilité quasi certaine, il y a tellement de flou et de biais possibles dans la problématique exposée, qu'elle me semble bien "improbable" à déterminer.

[CinePhil]

Envoyé par maestro1303

Cette table est renouvelée tous les jours et plusieurs cas peuvent se présenter:
1) un même mobile peut se retrouver dans toutes les éditions et être toujours dans la même zone
2)un même mobile peut se retrouver dans toutes les éditions et changer de zone
3) de nouveaux Num_Mobile peuvent apparaitre au gré des jours
4) des Num_Mobile peuvent disparaitre un moment puis réapparaitre

"Table renouvelée" veut dire que la table est vidée puis réalimentée ou complétée des données du jour ?
"éditions" veut dire archives de la table les jours précédents ?

Bref, il faudrait être plus précis dans la description pour qu'on puisse vous aider efficacement.

[Yanika_bzh]

Le meilleur procédé pour avoir une réponse certaine de la zone c'est d'appeler le GSM et de lui demander !

Sinon je rejoins Maljuna Kris sur la facon de faire et de penser...

Bon courage

[maestro1303]

Merci Maljuna Kris, merci CinePhil,merci Yanika_bzh,

Je vous remercie de ces réponses rapides.

J'ai écris un post long mais qui n'est qui n'est malheureusement pas arrivé.

Les tables ne sont pas vidées et ont exactement la même structure.

Table T20111015 correspond à la table de la journée du 15/10/2011
puis table T20111016 puis T20111017... etc.


Dans la table T20111015 on l'enregistrement 123456789 pour le champ num_mobile et 10119Z151 pour le champ Code_Zone_Géo

Dans la table T20111016 on l'enregistrement 123456789 pour le champ num_mobile et 10119Z151 pour le champ Code_Zone_Géo

Dans la table T20111017 on l'enregistrement 123456789 pour le champ num_mobile et 10119Z151 pour le champ Code_Zone_Géo

Dans la table T20111018 on l'enregistrement 123456789 pour le champ num_mobile et 10111Z188 pour le champ Code_Zone_Géo

Sur les 4 observations 3 montrent que le num 123456789 a été retrouvé dans la zone 10119Z151 (il y est donc avec la probabilité de 0.75)

et dans la zone 10111Z188, il a été trouvé 1 fois sur 4(il y est donc avec une probabilité de 0.25).


PS: je ne sais pas s'il faille prendre une table avec une autre structure afin d'y faire le comptage (count(*)... group by Code_Zone_Géo) et l'"incrémenter" par les résultats de chaque nouvelle observation dans une nouvelle table T2011mmjj, ou faire autrement.

Merci beaucoup et désolé pour le post que j'ai fait précédemment et qui n'a pas été pris en compte(espérant que celui ci ne le soit pas).

Yanika_bzh, s'il faut vraiment que l'on appelle les gens sur leur mobile je t'enverrais un groupe de numéros que tu va faire sur ton propre crédit

[Maljuna Kris]

Envoyé par maestro1303

désolé pour le post que j'ai fait précédemment et qui n'a pas été pris en compte(espérant que celui ci ne le soit pas).

Alors pourquoi le poster ?

[CinePhil]

S'il y a une table par jour avec la même structure, je suppose qu'il y a un grand nombre de tables ?
Sur quelle durée doit être fait le comptage ?

La bonne solution aurait été d'ajouter une colonne "date_donnee' et d'insérer les lignes du jour dans cette table unique. Dès lors, il serait facile de compter le nombre de fois qu'on trouve chaque numéro de téléphone dans les zones où il se trouve puis d'en tirer le pourcentage. Par exemple pour le mois de septembre :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT num_mobile, Code_Zone_Geo, 
	COUNT(t1.*) AS nb_de_fois,
	COUNT(t1.*) / t2.total AS proportion_dans_zone
FROM la_table t1
INNER JOIN
(
	SELECT num_mobile, COUNT(*) AS total
	FROM la_table
	WHERE date_donnee BETWEEN '2011-09-01' AND '2011-09-30'
	GROUP BY num_mobile
) t2 ON t2.num_mobile = t1.num_mobile
WHERE date_donnee BETWEEN '2011-09-01' AND '2011-09-30'
GROUP BY num_mobile, Code_Zone_Geo
ORDER BY num_mobile, Code_Zone_Geo

[Yanika_bzh]

Je pense que votre calcule de probabilité, bien qu'exacte techniquement n'est pas tres reprensentatif d'une probabilité réélle. En effet la date est importante et devrait pondérer vos résultat.


Si pour un numero de tel, vous avez 80% dans une zone A et 20% dans une zone B, mais que les 20% sont consécutifs et chronologiquement tous postérieurs aux 80% autres, votre probabilité que ce N° de tel soit dans la zone B est plus importante non ?

Comme le précaunise Cinephil, une colonne date devrait etre envisagée, vous n'aurez qu'une table unique (indépendance de votre fonctionnel et de votre architecture), vos requetes seraient plus facile a ecrire (cout de developpement et surtout de maintenance réduit), et beaucoup plus evolutives

Yanika_bzh, s'il faut vraiment que l'on appelle les gens sur leur mobile je t'enverrais un groupe de numéros que tu va faire sur ton propre crédit

Avec les forfaits illimités, y'a plus de pb !!

[maestro1303]

Merci beaucoup de toutes ces réponses.

L'idée de la table est géniale (je dois juste prendre comme nouvelle clé le N°GSM+la_date). Seul petit pb chaque jour j'ai environ 2 millions d'enregistrements par table. On peut aller jusqu'où dans mysql?

Si pour un numero de tel, vous avez 80% dans une zone A et 20% dans une zone B, mais que les 20% sont consécutifs et chronologiquement tous postérieurs aux 80% autres, votre probabilité que ce N° de tel soit dans la zone B est plus importante non ?

Tout à fait d'accord, sans oublier aussi les jours fériés où les gens ont tendance à rester chez eux pour ceux qui ne prennent pas des vacances etc....

Merci encore une fois.

[CinePhil]

Envoyé par maestro1303

Seul petit pb chaque jour j'ai environ 2 millions d'enregistrements par table. On peut aller jusqu'où dans mysql?

Très loin, comme avec n'importe quel SGBD. Personnellement, j'ai trravaillé avec des tables jusqu'à plus de 60 millions de lignes.

Mais la question que tu dois te poser pour définir la grosseur de ta table, c'est pendant combien de temps tu conserves ces données pour tes statistiques ?

J'ai déménagé début juillet. La situation géographique de mon téléphone est-elle encore pertinente sur les 9 premiers mois de l'année alors que les deux tiers sont obsolètes ?

[maestro1303]

Merci CinePhil,

Je conserve au maximum pour 20j ou un mois(à tout casser). Sinon je change de table avec la même structure et j'archive l'ancienne au cas où.

Effectivement quelqu'un qui déménage fausse tout, donc petite consigne pour ne pas perturber nos statistiques on reste au bercail SVP!

Merci beaucoup

[maestro1303]

Bonjour à tous,

J'ai à présent une mega table avec les numéros et les zones par date.

Exemple pour le numero 06251512 :
06251512 Z1 20111101
............. .... ..............
06251512 Z1 20111102
............. .... ..............
06251512 Z1 20111103
............. .... ..............
06251512 Z3 20111104
............. .... ..............
............. .... ..............
06251512 Z1 20111105

Auriez vous SVP une idée pour une requête qui me donne pour chaque numéro comme 06251512 le nombre de fois qu'il a été dans chaque zone
pour le numero en exemple:
06251512 a été 4 fois en Z1 et 1 fois en Z3

Merci infiniment de votre aide.

[CinePhil]

Ben un GROUP BY sur le numéro de tel et la zone et un COUNT dans le SELECT devrait faire l'affaire non ?

Regarde ma requête du message #2.

[maestro1303]

Merci beacoup CinePhil de tes réponses qui m'ont bien permis d'avancer. Nous y sommes (ou presque).
Voici la dernière requête que j'ai émise mais qui ne donne toujours pas ce que je cherche :

Code :

SELECT count(*),numero, zone FROM Grosse_table GROUP BY numero

Au fait voilà ce que je voudrais avoir

numero......1ereZone_occ......2èmezone_occ.....3èmezone_occ...... dernièreZone
123456...... Z8_10 ...................Z12_7.....................Z2_3 ...................... Z12
123856...... Z3_11 ...................Z8_9................. .....Z1_5........................Z4
123457...... Z8_5.......................Z12_4............... .....Z6_3........................Z7
123459...... Z8_7......................Z11_4....................Z1_2 ........................Z11

Avec Zi_occ telle que Zi est une zone et occ est l'occurence du numéro dans Zi(cad le nombre de fois où le numéro a été localisé dans Zi)

dernièreZone représente la dernière zone en terme de date où le numéro a été localisé.

Comme vous me l'avez suggéré, j'ai une table regroupant tous les numéros avec leur localisation et la date de localisation:

structure de la table "Grosse_table"
numero,zone,date

[CinePhil]

Le résultat que tu cherches à obtenir est plutôt du ressort du logiciel qui présente les données à l'utilisateur que celui du SGBD.

On ne sait en effet pas, a priori, dans combien de zones un numéro sera trouvé. Il faudrait utiliser de la récursivité... qui n'existe pas chez MySQL !

Quant à ta requête, tu n'as pas dû bien regarder le lien que j'ai donné sur le GROUP BY ni ma requête car tu as oublié zone dans le GROUP BY !

Code :

1
2
3
SELECT numero, zone, count(*) AS nombre 
FROM Grosse_table 
GROUP BY numero, zone

Cela te donnera un résultat de ce genre :
numéro / zone / nombre
06251512 / Z1 / 4
06251512 / Z3 / 1

Si tu veux trier par plus gros nombre pour chaque numéro, il suffit d'ajouter un ORDER BY :

Code :

1
2
3
4
SELECT numero, zone, count(*) AS nombre 
FROM Grosse_table 
GROUP BY numero, zone
ORDER BY numéro, count(*)

[maestro1303]

Merci beaucoup de cette réponse.

J'ai une liste qui peut être traité en deux 2 temps pour avoir ce que je veux:

numero......1ereZone_occ......2èmezone_occ.....3èmezone_occ...... dernièreZone
123456...... Z8_10 ...................Z12_7.....................Z2_3 ...................... Z12
123856...... Z3_11 ...................Z8_9................. .....Z1_5........................Z4
123457...... Z8_5.......................Z12_4............... .....Z6_3........................Z7
123459...... Z8_7......................Z11_4....................Z1_2 ........................Z11

Au fait pour chaque abonné je veux avoir en premier la zone où il a été le plus fréquent. En deuxième la zone suivante en terme de fréquence et en troisième la zone suivant la 2ème en terme de fréquence.
Si par exemple il n'a été présent que dans une seule zone, je mets les 2 autres à blanc ou 0 etc. Si par contre il a été présent dans 6 zones différentes je n'affiche que les 3 où il a été le plus fréquent suivant le principe précédent.

Votre réponse précédente me résout mon oroblème à 90%. Il reste néanoins quelques détails à regler pour avoir les données en sortie, car avec phpMyadmin, j'ai le message suiavnt

Fatal error: Maximum execution time of 300 seconds exceeded in C:\Program Files\EasyPHP-5.3.3.1\phpmyadmin\libraries\dbi\mysql.dbi.lib.php on line 176

Et avec la console j'ai aussi une erreur de droit d’écriture sur le disque.

Error logging to file '"d:/\sortie.txt"'

Merci infiniment.
Je sais que je deamnde trop de choses à la fois

[maestro1303]

Bonjour CinePhil, Bonjour à tous,

Merci de ne pas tenir compte de la deuxième partie de ma demande qui concerne le fichier de sortie: elle a été réglée par qq'1 de ce même forum, en l'occurrence lenono (que je remercie au passage).

Merci infiniment.