Discussion :

[Invité]

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 MYSQL :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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

Merci de m'aiguiller.

[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.

[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.

[Invité]

Bonjour,

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.

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 ?

Il n'y a pas un moyen de mettre d'une autre manière les "rank" avec " rankcolumn " ou " rankline " du coup ?

[sabotage]

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

[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.

[Invité]

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.

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

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 .

[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.

[Kasko]

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?

[Invité]

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.

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

[sabotage]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select @position:=@position+1 position, colonneA, colonneB FROM table, (SELECT @position:=0) p;

[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

[sabotage]

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

[Invité]

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.

[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.

[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 !