Numérotation automatique défaillante

Version imprimable

04/12/2015, 10h35
Invité

Numérotation automatique défaillante
Bonjour,

Je rencontre une problème assez cocasse et je ne trouve pas de solution plossible .

Je m'explique :

J'ai un base test PHPMyadmin dans la quelle je viens alimenter une table de 60 colonnes. Il y a 2 types de formats , du texte et du numérique selon les colonnes. Il a y bien entendu une clef primaire qui est un numéro automatique. Ce numéro s'incrémente au fur et à mesure de l'alimentation des lignes.

Sauf que j'en ai découverte une bien bonne en contrôlant les données :

L'incrémenteur dérappe et me gonfle le compteur .

Supposons que je pousse une fichier de données de 100 000 lignes. J'aurai un compteur de 1 à 90 000 , rien de 90 001 à 100 000 puis une reprise de 100 001 à 110 000 . C'est comme ci des lignes disparaissaient ou bien qu'il y avait des lignes fantomes.

Requête SQL que j'utilise pour faire mon import de données :
Code:

1 2 LOAD DATA INFILE 'C:\mondossier\monfichier.csv' replace INTO TABLE matable FIELDS TERMINATED BY ';' ;
J'ai controlé , j'ai:

- aucune perte de données car je retrouve bien toutes les lignes dans la base.
- le compteur augmente de façon aleatoire tout seul, quand je vais dans mes BDD >> ma base >> ma table >> opération >> je contrôle le chiffre afin de m'assurer de la position du compteur qui est 1 fois sur 2 plus loin que le nombre de ligne réelle de la base. (exemple 100 000 ligne en base , 110 000 pour le compteur automatique).
- aucune ligne vide dans mes fichiers txt ou csv que je pousse dans la table.

La "trou" dans le comptage est complétement aléatoire , défois c'est 10 lignes pour un gros fichier , comme cela peut être 4000 à 5000 lignes pour un fichier ridicule de 10 lignes. :weird:

Pour information j'alimente ma table via des fichiers CSV ou txt par un .bat qui execute un qbquery mysql.

Merci de m'aiguiller. ;)
04/12/2015, 11h45
sabotage

D'apres les informations qu'on trouve, mysql reserve les id pour l'insertion mais ne reserve pas le nombre exact. Ca peut donc laisser des trous.

Cependant les id n'ont que l'obligation d'être uniques, pas de se suivrent.
04/12/2015, 11h49
Kasko

Salut,
Je pense que soit lors de la création de ta table tu as forcé le SGBD de commencer la numérotation à partir de 10 soit tu as fait une suppression de 10 lignes auparavant.
04/12/2015, 12h04
Invité

Bonjour,

Citation:

Envoyé par Kasko

Salut,
Je pense que soit lors de la création de ta table tu as forcé le SGBD de commencer la numérotation à partir de 10 soit tu as fait une suppression de 10 lignes auparavant.

Justement non je ne supprime aucune ligne. A la limite j'update les lignes pour test puis je la réinjecte en base pour écraser l'ancienne.

Citation:

Envoyé par sabotage

D'apres les informations qu'on trouve, mysql reserve les id pour l'insertion mais ne reserve pas le nombre exact. Ca peut donc laisser des trous.

Cependant les id n'ont que l'obligation d'être uniques, pas de se suivrent.

D'où les approximations du nombre de lignes lors de l'aperçu ?

C'est vraiment très génant car comment peut procéder à un algorithme sur la base qui demanderait l'utilisation d'une boucle for ? :weird:

Il n'y a pas un moyen de mettre d'une autre manière les "rank" avec " rankcolumn " ou " rankline " du coup ? :(
04/12/2015, 12h22
sabotage

On ne travaille pas comme ça avec un SGDB justement ;)
Que veux-tu faire exactement ?
04/12/2015, 12h29
Kasko

Je vais dire avant même d'importer ton CSV(lors des tests par exemple) t'es sûr que t'as rien supprimé dans ta table et t'as pas aussi ordonné le SGBD de commencer la numérotation à partir de 10?La plupart de temps cela arrive si par exemple l'on exporte sa base ou sa table avec des enregistrements.Donc le jour où l'on importe le même script,par défaut la nouvelle numérotation commence à partir du dernier enregistrement(11 si le dernier enregistrement est 10) sauf si l'on personnalise.Pour ce qui de la mise à jour,je pense pas que ça peut impacter la numérotation sauf si tu touches à l'identifiant.Sinon si j'ai bonne mémoire,quand on exécute un fichier CSV,ce dernier s'assure d'abord que l'identifiant n'existe pas en base avant d'insérer une ligne sinon il passe à l'enregistrement suivant.
04/12/2015, 13h52
Invité

Citation:

Envoyé par sabotage

On ne travaille pas comme ça avec un SGDB justement ;)
Que veux-tu faire exactement ?

Je souhaite que mon id , soit :

- un numéro affecté de façon automatique
- l'id doit être égal au numéro de la ligne (si id = 60 000 alors la ligne de données est la 60 000 et pas la 65 000)
- l'id est à la fois un id est un numéros d'ordre. Exemple dans le cadre de l'execution d'une boucle for.

Citation:

Envoyé par Kasko

Je vais dire avant même d'importer ton CSV(lors des tests par exemple) t'es sûr que t'as rien supprimé dans ta table et t'as pas aussi ordonné le SGBD de commencer la numérotation à partir de 10?

J'ai pris soin de faire comme suit :

- création d'une nouvelle table
- injection de X ligne en base
- maj d'un certain nombre de ligne (dont écrasement des précédentes)
- ajout de nouvelles lignes

Citation:

Envoyé par Kasko

La plupart de temps cela arrive si par exemple l'on exporte sa base ou sa table avec des enregistrements.Donc le jour où l'on importe le même script,par défaut la nouvelle numérotation commence à partir du dernier enregistrement(11 si le dernier enregistrement est 10) sauf si l'on personnalise.Pour ce qui de la mise à jour,je pense pas que ça peut impacter la numérotation sauf si tu touches à l'identifiant.Sinon si j'ai bonne mémoire,quand on exécute un fichier CSV,ce dernier s'assure d'abord que l'identifiant n'existe pas en base avant d'insérer une ligne sinon il passe à l'enregistrement suivant.

Il est vrai que le second problème (toucher à un numéro auto) m'a déjà conduit à ce que ma numérotation saute et foire. Mais je n'ai pas touché dans ici dans le cas présent du problème actuel.

On est bien avec ma table test de 100 000 lignes ici .
04/12/2015, 14h29
sabotage

Tu me redis ce que tu aimerai du point de vue mysql mais tu ne me dis pas pourquoi.
Les résultats d'une requête ne se parcoure pas avec une boucle for justement.
L'id est un reference, pas une position de classement. Dis nous ton besoin fonctionnel exact et on pourra te dire comment le réaliser.
04/12/2015, 15h34
Kasko

Citation:

Envoyé par tanaka59

J'ai pris soin de faire comme suit :

- injection de X ligne en base
- maj d'un certain nombre de ligne (dont écrasement des précédentes)
- ajout de nouvelles lignes

Peut-tu nous expliciter cela et si possible nous dire comment t'as fait avec ces lignes au moments où tu veux importer ton CSV?
05/12/2015, 00h46
Invité

Citation:

Envoyé par sabotage

Tu me redis ce que tu aimerai du point de vue mysql mais tu ne me dis pas pourquoi.
Les résultats d'une requête ne se parcoure pas avec une boucle for justement.
L'id est un reference, pas une position de classement. Dis nous ton besoin fonctionnel exact et on pourra te dire comment le réaliser.

Un besoin , fonctionnel > pouvoir avoir de manière automatique un numéro pour des tickets , des enregistrement d'action via des opérations logique qui se suivent, via des robots (envoi de mail par un robot d'archivage). L'id était un numéro automatique.

Ici ce type d'id m'a déjà servi dans le cas d'une analyse temporelle continue. Il est a la fois id de période et variable dans un calculs multi variées. Comme on se sert d'un id automatique qui est aussi une variable pour alimenter le tableau d'analyse il ne peut y avoir aucun trou. Par exemple une anova, une analyse temporelle avec le trend, obligatoirement il faut identifier les périodes qui se suivent.

Citation:

Envoyé par Kasko

Peut-tu nous expliciter cela et si possible nous dire comment t'as fait avec ces lignes au moments où tu veux importer ton CSV?

1) je créé un table dans phpmyadmin
2) je créé un bat pour exécuter un qbquery
3) je créé un qbquery avec la requête mysql
4) je crée une requête avec load data pour charger la table
5) j'exécute le bat pour exécuter le qbquery qui va lui même exécuter la requête mysql pour charger les données dans phpmyadmin
05/12/2015, 06h32
sabotage

Tu peux numéroter tes résultats de requête :

Code:

select @position:=@position+1 position, colonneA, colonneB FROM table, (SELECT @position:=0) p;
05/12/2015, 17h11
Invité

Bonsoir ,

Je prend bonne note des informations sur la numérotation automatique de PHPMyAdmin qui est aussi aléatoire. Pas très fiable comme système en effet.

Quoi qu'il en soit je note la chose sous le coude c'est toujours très important de le savoir !

Je testerai la requête avec numéro de position ;)

Merci des aiguillages ;)
05/12/2015, 17h25
sabotage

Elle est fiable : elle fourni un id de référence unique.
06/12/2015, 23h39
Invité

Citation:

Envoyé par sabotage

Elle est fiable : elle fourni un id de référence unique.

Pour donner un id elle est fiable .

S'en servir comme compteur automatique n'est pas fiable (dixit : numéroter des tickets de demandes utilisateurs par exemple ) . Avec des trous dans la numérotation cela ne permets d'avoir une numérotation fiable . Si il y a 4000 tickets utilisateurs et que le compteur dit 4500 alors ce cas fonctionnel prouve la non fiabilité du numéro automatique.
07/12/2015, 13h57
sabotage

L'id n'est pas fait pour compter des lignes, donc il est fiable.
C'est comme si tu me disais qu'une fourchette n'est pas fiable car tu n'arrives pas à peindre avec.
08/12/2015, 22h42
Invité

L'algorithme qui numérote les id n'est pas très fiable.

Depuis quand une numérotation comporte des tous ? Quand tu utilises un incrementeur le pas définit est bien de 1 en 1 . Et non de 1 en 1 puis 1 en 5 , puis 1 en 10 et de nouveau 1 an 1 ... Cela n'a pas de sens !