Discussion :

[noradan]

bonjour
j'ai l'impression (c'est même sûr) que lorsque je modifie ma BDD avec une instruction "INSERT INTO `matable` VALUES etc

le numéro ID qui est en incrément auto ne prend pas en compte le dernier numéro écrit mais un compteur interne qui tient compte de toutes les insertions faites
si bien que si l'on supprime des lignes on se retrouve avec des trous dans les numéro d'ordre.

Comment peut-on faire pour que ce compteur ait la valeur du dernier ID écrit dans la table?

Merci

[casperweb]

si bien que si l'on supprime des lignes on se retrouve avec des trous dans les numéro d'ordre.

Bonsoir, oui, c'est normal et cela ne pose aucun problème. Le SGBD gère très bien cela.

Comment peut-on faire pour que ce compteur ait la valeur du dernier ID écrit dans la table?

LAST_INSERT_ID() c'est indiqué dans la FAQ
https://mysql.developpez.com/faq/?pa...autoincremente

[SQLpro]

Aucun système d'auto incrément ne "récupère" les trous. Sinon il faudrait des transactions tellement bloquante qu'un seul utilisateur ne pourrait jamais insérer puisqu'il faudrait bloquer les autres utilisateurs si l'un fait une insertion. Or un SGBDR est fait pour servir un maximum d'utilisateur à la fois. De plus l'attribution d'une nouvelle valeur est arbitraire dans le sens ou le système (IDENTITY ou SEQUENCE selon la norme SQL) peut recommencer au début si l'on a épuisé les valeurs séquentielle, ou encore, vous pouvez vous même réajuster les valeurs de départ et le pas d'incrément qui n'est pas forcément de 1.

Lisez mon cours sur le SQL à ce sujet :
https://sqlpro.developpez.com/livre/...ions#LIII-10-5

A +

[escartefigue]

Lisez mon article de blog à ce sujet ICI

[noradan]

Oh je me doute bien que ça ne pose aucun problème puisqu'en théorie on se fiche pas mal de la valeur de l'id.
C'est un peu esthétique pour moi !
Ma table a 32 lignes et le compteur est à 157 ça fait un peu bizarre !

LAST_INSERT_ID ne répond pas à ma question si j'ai bien lu.
Je ne veux pas récupérer la valeur, je l'ai sous les yeux... je voudrais qu'après avoir supprimer 120 lignes le compteur passe à 33 et pas 158!
Mais si j'en crois ton blog "escartefigue" il n'y a pas moyen... Méééheu !

C'est comme dans une liste numérotée (et pas "ordonnée" comme on dit en html, une liste étant TOUJOURS ordonnée par définition d'une liste !)
En théorie on pourrait numéroter n'importe comment (du moment que ça reste croissant...) mais ça ferai un peu étrange d'avoir une liste 1, 7, 12, 94 ...

La raison, histoire de raconter ma vie, est que je fais fabriquer un fichier php dans lequel je fais écrire automatiquement une valeur de VALUE
comme mon programme (python) n'est pas encore tout à fait au point, je dois intervenir à la main, je corrige, je relance, je recorrige et je rerelance etc et à chaque fois
il y a quelque ligne de VALUE qui passe mais ui répètent la même chose du coup j'ai une foultitude de ligne identiques que je détruit à la fin sauf que le compteur
garde la dernière valeur en mémoire.

[tatayo]

Bonjour,
Hypothèse:
Le "compteur" est à 0.

1. L'utilisateur A débute une transaction, et insère une ligne dans la table
2. L'utilisateur B débute une transaction, et insère une ligne dans la table.
3. L'utilisateur B valide sa transaction
4. L'utilisateur A annule sa transaction

Quel est l'identifiant de la ligne insérée par l'utilisateur B ? 2. Le 1 avait été "réservé" par l'utilisateur A.
Si tu veux numéroter les lignes "par ordre d'insertion", une solution serait de les horodater avec un timestamp, dont la valeur est current_timestamp().
Reste à voir si la valeur est "calculée" à l'insertion de la ligne, ou à la validation de la transaction (à mon avis c'est à l'insertion).

Tu peux aussi utiliser un RANK() pour numéroter les lignes à la génération du fichier. Mais la rang calculé risque fort de changer d'un export à l'autre, suivant la colonne utilisée pour le "calcul" du rang (l'horodatage indiqué précédemment).

Mais un Id reste un Id, sans aucune signification.

Tatayo.

[noradan]

Evidemment tout ceci est vrai mais je suis le seul et unique utilisateur de la BDD: fabriquant, intervenant, utilisateur, etc
il n'y a que moi qui insère ou détruit.

C'est sans grande importance

J'aurais bien aimé si cela avait été possible pour un unique "propriétaire" d'une table.

Merci

[escartefigue]

Même en étant le seul utilisateur, il peut y avoir plusieurs threads.

Quoi qu'il en soit, un identifiant attribué par le SGBD (identity, counter, serial, auto_increment... selon le sgbd) ne doit jamais être utilisé pour un besoin fonctionnel.

[kick54]

Evidemment tout ceci est vrai mais je suis le seul et unique utilisateur de la BDD: fabriquant, intervenant, utilisateur, etc
il n'y a que moi qui insère ou détruit.

C'est sans grande importance

J'aurais bien aimé si cela avait été possible pour un unique "propriétaire" d'une table.

Merci

Bonjour,

... Avec tous inconvénients, aléas et précautions déjà énoncées, si ton SGBD dispose des Triggers, tu te passes de l'auto-incrément sur id (que tu déclares entier) et tu utilises un Trigger dans une pré-condition sur INSERT dans laquelle tu calcule la nouvelle valeur de id.
Le code sera du genre :

Code :

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

BEFORE INSERT ... SELECT Max(id) + 1 FROM table

Tu peux aussi le faire dans le code qui produit l'insertion d'un nouvel enregistrement.

C'est un poil lourd, mais à vue de nez ça doit passer ;-)


Cdlt

[Michel.Priori]

Oh je me doute bien que ça ne pose aucun problème puisqu'en théorie on se fiche pas mal de la valeur de l'id. C'est un peu esthétique pour moi !

Oh, l'esthétique...
l'esthétique d'une liste... d'informations stockées dans une base...
Est-ce bien LA problématique ?

Ma table a 32 lignes et le compteur est à 157 ça fait un peu bizarre !

32 lignes.
Pourquoi avoir choisi un compteur ?
Pas moyen de numéroter "à la main" ?

LAST_INSERT_ID ne répond pas à ma question si j'ai bien lu.
Je ne veux pas récupérer la valeur, je l'ai sous les yeux... je voudrais qu'après avoir supprimer 120 lignes le compteur passe à 33 et pas 158!
Mais si j'en crois ton blog "escartefigue" il n'y a pas moyen... Méééheu !

Alors, oui, il y a un moyen : https://learn.microsoft.com/fr-fr/sq...l-server-ver17
mais attention, ça ne touche que la génération de valeurs ; rien ne dit que la valeur à venir contredise ou pas l'unicité imposée de la PK
Note : l'instruction TRUNCATE purge les lignes et remet le compteur à zéro.

C'est comme dans une liste numérotée (et pas "ordonnée" comme on dit en html, une liste étant TOUJOURS ordonnée par définition d'une liste !)
En théorie on pourrait numéroter n'importe comment (du moment que ça reste croissant...) mais ça ferai un peu étrange d'avoir une liste 1, 7, 12, 94 ...

Il y a une GRANDE différence entre une clé, ce qui fait office de pointeur, et une projection, le résultat d'une interrogation.
Si vous voulez voir une liste ordonnée et dense, il faut utiliser dans la projection une fonction de fenêtrage.
Dans votre cas, je choisirais ROW_NUMBER : https://learn.microsoft.com/fr-fr/sq...l-server-ver17

ce qui donnerait, par exemple :

Code :

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

1
2
SELECT row_number () over (order by id asc) as numero, t.colonne
FROM matable t

[escartefigue]

Si tu veux numéroter les lignes "par ordre d'insertion", une solution serait de les horodater avec un timestamp, dont la valeur est current_timestamp().
Reste à voir si la valeur est "calculée" à l'insertion de la ligne, ou à la validation de la transaction (à mon avis c'est à l'insertion).

Attention : si les risques de doublons de timestamp sont marginaux, pour autant, un timestamp n'est pas unique par construction.
Avec une CPU de fréquence très élevée et très peu d'activité sur la machine, un doublon reste possible. Donc, dans l'absolu, un timestamp seul ne peut pas servir d'identifiant, défaut d'unicité oblige

[tatayo]

La "solution" que je propose n'a pour seul but de permettre de trier les lignes par ordre d'insertion.
Il ne s'agit pas de remplacer un id, qui pour moi n'a qu'une seule fonction : identifier une ligne.

Tatayo

[SQLpro]

Bonjour,

... Avec tous inconvénients, aléas et précautions déjà énoncées, si ton SGBD dispose des Triggers, tu te passes de l'auto-incrément sur id (que tu déclares entier) et tu utilises un Trigger dans une pré-condition sur INSERT dans laquelle tu calcule la nouvelle valeur de id.
Le code sera du genre :

Code :

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

BEFORE INSERT ... SELECT Max(id) + 1 FROM table

Tu peux aussi le faire dans le code qui produit l'insertion d'un nouvel enregistrement.

C'est un poil lourd, mais à vue de nez ça doit passer ;-)


Cdlt

Solution totalement pourrie par ce qu'elle oblige à un verrouillage total (lecture et écriture) de l'intégralité de la table pour ce faire.

C'est comme cela que l'on détruit les performances des SGBDR et qu'ensuite on vient se plaindre que c'est lent !

A +