Auto incrémentation en cas de suppression d'enregistrement

Bonjour,
j'ai une table avec l'id en auto incrémentation(ma table contient pour l'instant juste deux lignes) :
Ma première ligne a un id 1
Ma deuxième ligne un id 3 (elle devrait avoir un id 2)
Avant d'ajouter ma deuxième ligne j'en avais créé une mais effacée par la suite.
Est-ce que pour les enregistrement effacés la table garde l'id en mémoire.
Je me pose cette question parce que si par la suite je vais faire des requetés : select... from table where id = 2, ca posera des problèmes je suppose.
Comment palier à ce problème ?
merci

Bonjour,
Un identifiant n'a "pas de sens", donc j'ai envie de dire "on se moque un peu de sa valeur".
Donc la présence de trous dans la numérotation n'a aucune importance.

De mon point de vue, il faut ajouter dans ta table un code qui te servira à identifier chaque ligne au sens applicatif/utilisateur.
L'identifiant auto servira de clé primaire, et sera utilisé dans les jointures/clés étrangères.

Pour info toutes mes tables ont un identifiant auto, et si je prends par exemple la table pays, l'identifiant commence à ... 218.
Et pour ma table des langues, l'identifiant commence à 81.
Ou, j'ai fait pas mal de tests, avec des ajouts/suppressions en pagaille.
Mais peu importe, si je cherche un pays en particulier je me base sur un code iso, pas un identifiant auto dont je ne connais pas la valeur.

Tatayo.

Citation:

---

Envoyé par tatayo

Bonjour,
Un identifiant n'a "pas de sens", donc j'ai envie de dire "on se moque un peu de sa valeur".
Donc la présence de trous dans la numérotation n'a aucune importance.

---

Si cet ID représente la numérotation des factures, ça a de l'importance. On peut toujours faire un truc du genre :

Code:

---

FAC_ID INTEGER DEFAULT (MAX(FAC_ID) + 1) NOT NULL

---

Mais un rédacteur de ce site explique dans un tutoriel que ça peut être catastrophique en utilisation client/serveur et je n'ai pas bien compris pourquoi.

Citation:

---

Envoyé par Nerva

Si cet ID représente la numérotation des factures, ça a de l'importance. On peut toujours faire un truc du genre :

Code:

---

FAC_ID INTEGER DEFAULT (MAX(FAC_ID) + 1) NOT NULL

---

---

Effectivement c'est particulièrement imbécile.... pour de nombreuses raisons !
1) pour assurer la stabilité du calcul du MAX il faut verrouiller l'intégralité de la table en mode exclusif... Sinon le calcul peut être faussé si un utilisateur concurrent modifie une donnée au cours de l'exécution de la requête. Donc au fur et à mesure de la montée en charge cela prendra de plus en plus de temps jusqu'à des attentes insupportables pour les utilisateurs.
2) en cas de suppression il y aura des trous, sauf à renuméroter
3) une telle contrainte par défaut n'est accepté sur pratiquement aucun SGBDR digne de ce nom... SQL Server, Oracle, IBM Db2, PostGreSQL...

La solution consiste, comme souvent à faire ce que l'on faisait autrefois sans l'informatique... Les factures étaient éditées sur des facturiers qui était des cahiers préimprimés triplicata numérotés. En cas d'erreur sur une facture on barrait le texte et on mettait la mention "ANNULÉE" en travers.
Il s'agit de faire de même, en ne supprimant JAMAIS aucune ligne de facture et en ajoutant la valeur TRUE à une colonne nommé FACTURE_ANNULEE tout simplement !

A +

Dit autrement

Un identifiant technique (identity, auto_increment, number ou serial selon le SGBD) répond à des exigences... techniques. Lapalice n'aurait pas dit mieux.
Il est géré par le SGBD et pour le SGBD de façon à garantir l'unicité. Point barre.

Un identifiant fonctionnel de son côté répond à des exigences réglementaires ou métier.
Il est évident qu'un SGBD peut être utilisé dans toutes sortes de contextes réglementaires ou métier, le moteur du SGBD ne peut donc pas prévoir toutes les contraintes métier, ce n'est pas son job.

Concernant le n° de facture, il faut réglementairement qu'il soit non seulement unique, mais aussi sans trous.
L'apparition de "trous" dans des identifiants techniques peut avoir plusieurs causes

• suppression physique de lignes par DELETE ;
• lignes insérées mais non commitées ;
• valeur initiale de l'identifiant différente de 1 ;
• pas d'incrément ou de décrément différent de 1.

Bref, vous l'aurez compris, qu'on soit en environnement client-serveur ou pas ne change rien à l'affaire !

Citation:

---

Envoyé par escartefigue

...
L'apparition de "trous" dans des identifiants techniques peut avoir plusieurs causes

• suppression physique de lignes par DELETE ;
• lignes insérées mais non commitées ;
• valeur initiale de l'identifiant différente de 1 ;
• pas d'incrément ou de décrément différent de 1.

---

Tu en as un dernier : le redémarrage d'un serveur SGBDR si il y a mise en cache des autoincréments... Dans ce cas, les autoincréments cachés sont perdus... Il est donc conseillé de ne pas mettre en cache les autoincréments pour les factures !

A +

Bonsoir,
j'ai lu avec beaucoup d'intérêt vos échanges très pro et passionnant , étant débutant cela m'aide à mieux comprendre le fonctionnement des SGBD.
Merci à vous de me consacrer du temps.
Bonne soirée

Merci des précisions, mais je mettais surtout en avant (comme l'auteur, d'où mon intervention) un problème qui concerne la dernière ligne supprimée, et celle que l'on ajoute après, que l'on voudrait numérotée sans trou (d'ailleurs, même si il n'y a pas d'obligation particulière à ne pas avoir de trous).

Quant à la facturation papier d'avant, il y a deux possibilités : soit il s'agit d'une erreur humaine de remplissage et on annule la facture, soit il s'agit d'un client qui se rétracte (ou autre) et dans ce cas on lui fait une facture d'avoir (et ça suivra selon la procédure au niveau compta). Mais c'est vrai que dans les deux cas, on n'arrache pas la facture du facturier (ne rigolez pas, mais ça s'est vu) . ;)