pb pour l'auto-incrémentation

Bonjour,

Après avoir rechercher un peu partout sur le net, je n'arrive toujours pas à trouver une solution concernant le problème suivant :

je possède les données suivantes :

1, Durant
2, Dupont
6, Petit

Après avoir effacer mon 3, 4 et 5ème enregistrement dans ma base de donner MySql pour supprimer des clients, je souhaiterais utiliser le numéro 3 ainsi que les autres numéros (4,5,7,...) pour d'autres clients.

Existe t'il un code pour régler ce problème ? une réinilialisation de l'auto-incrémentation est possible ?

Merci d'avance ;)

Bonjour,

Je n'ai pas la réponse à ta question (du moins pas dans le cadre de l'usage avec MySql) mais te suggére de la mettre plutôt dans le forum ad-hoc (SGBD ....) où tu aurais sans doute plus de chance d'avoir une réponse, puisque ton problème ne dépend absolument pas du langage de programmation utilisé.

Ou sinon un moyen en utilisant le langage de programmation est de se faire sa fonction de traitement. Pour chaque ajout tu récupère l'id de tous les clients, et tu parcour ta liste d'id, et lorsque tu trouve un troue dans la liste, tu ajoutes le client avec l'id correspondant.

Citation:

---

Envoyé par ced600

Ou sinon un moyen en utilisant le langage de programmation est de se faire sa fonction de traitement. Pour chaque ajout tu récupère l'id de tous les clients, et tu parcour ta liste d'id, et lorsque tu trouve un troue dans la liste, tu ajoutes le client avec l'id correspondant.

---

Attention aux conflits entre utilisateurs !!!!

Citation:

---

Envoyé par Bluedeep

Attention aux conflits entre utilisateurs !!!!

---

je pense aussi mais concernant ce sujet c'est pour mon développement en c# et peut etre qu'il y a un code permettant de le réinitilaliser :roll::roll:

Ou alors, quand tu supprimes une ligne tu mets son id dans une Queue.
Au moment d'ajouter l'élément tu récupères l'id dans la Queue et tu l'assignes à ton élément.

Le mettre dans une Queue c'est-à-dire ??? :?

Citation:

---

Envoyé par matinho

Le mettre dans une Queue c'est-à-dire ??? :?

---

C'est une pile du style: "dernier entré, dernier sorti" ;)

Citation:

---

Envoyé par Thomas Lebrun

C'est une pile du style: "dernier entré, dernier sorti" ;)

---

On dit pas plutot "Premier entré, premier sortit" :) (FIFO?)

Mais dans son cas, s'il supprime dans l'ordre : 6 - 4 - 5, il faut ensuite trier, car il doit attribuer 4 avant 6?

Oulalala .... le terme de pile désigne en général un LIFO. Quand on un FIFO on parle plutôt de pipe. (ou un Queue, en effet, mais ce n'est pas une pile).

serait-il possible d'avoir un exemple svp ? :mouarf::mouarf::mouarf:

Citation:

---

Envoyé par matinho

Après avoir rechercher un peu partout sur le net, je n'arrive toujours pas à trouver une solution concernant le problème suivant :
.....
Existe t'il un code pour régler ce problème ? une réinilialisation de l'auto-incrémentation est possible ?

---

Reprenons depuis le début.

En dehors de l'aspect technique, quel est ton besoin fonctionnel ici ?

J'ai en effet un peu de mal à comprendre pourquoi tu veux utiliser une auto-incrémentation pour, ensuite, décider de réutiliser les entrées, ce qui est quelque peu antinomique. Ne faudrait il pas recommencer par là ? le "pourquoi".

********-------------------------
j'entre ->**********************-> je sors
********-------------------------

:mouarf:

Ok c'est moi qui sort :aie:

A mon avis, on est surtout sur le mauvais forum. C'est un problème totalement indépendant du langage qui devrait être envoyé dans le forum MySQL.

En faite, je fais une fiche d'inscription pour enregistrer des clients et dans ma base de donnée j'utilise une auto-incrémentation pour ne pas saisir les numéros de client lors de l'inscription.

Je voudrais savoir si je peux revenir sur les numéros qui ont été supprimé par l'intermédiaire de code en c# ...

(je ne pourais répondre que demain matin à partir de 9h, je ne vais pas avoir de connection internet pour ce soir)

merci d'avance si vous arrivez à trouver une solution ;)

Citation:

---

Envoyé par Kaidan

A mon avis, on est surtout sur le mauvais forum. C'est un problème totalement indépendant du langage qui devrait être envoyé dans le forum MySQL.

---

C'est en substance le contenu de ma première réponse. cf supra.

Bha il est clair que le mieux est que la base de données fassent se traitement.
Mais s'il insiste pour le faire en C# c'est son droit, et donc là une recherche sur le net au sujet des éléments devraient être suffisant.

Si besoin, voici une requête SQL qui récupère le prochain numéro en "bouchant les trous" :

Code:

---

1 2 3 4 5

SELECT COALESCE(MIN(id) + 1, 0) AS NEXTVALUE FROM matable r WHERE NOT EXISTS (SELECT id FROM matable r2 WHERE r2.id = r.id + 1)

---

Tout es possible bien entendu, mais tout n'est pas profitable.

Si le fait de récupérer les identifiants 'perdus' est justifié par une raison conceptuelle fondamentale, alors je comprends, sinon, c'est véritablement se donner beaucoup de mal pour pas grand chose. Il ne faut pas avoir peur de 'perdre' des Ids. Si ils sont codés sur 32 bits cela fait plus de 4 milliards d'entrée possibles... Cela laisse de la marge tout de même. Et au pire, il y a la possibilité de les coder sur 64 bits.

Maintenant, si cette fonctionnalité est indispensable alors il faut bien trouver une solution.

Pour ce qui me concerne, j'ai tenté d'adapter la reqête précédente à SQL serveur mais je ne suis pas parvenu à un résultat satisfaisant (J'en profite pour demander à SaumonAgile de l'expliquer car je ne vois pas comment elle peut répondre à la problématique. Mais que si elle y répond, je ne veux pas passer à coté). Quoi qu'il en soit, le temps de traitement d'une telle requête est directement lié au nombre d'enregistrements. Ce qui risque de poser de gros problèmes de performance. A moins vraiment que le nombre d'enregistrements reste limité. Mais si il est limité, pourquoi y-a-t-il tant besoin de récupérer les 'trous' ?

Cela ne me parait pas non plus très sage de conserver en mémoire les Ids 'perdus' car la mémoire c'est précieux et volatile.

Une solution consiterait à avoir recours à une petite table pour stocker les Ids 'perdus' et les retrouver par la suite.

Autre possibilité, plutôt que de supprimer les enregistrement, il pourrait être marqués. Il suffirait de mettre un des champs dans un état particulier. Il serait alors facile de trouver les 'trous' et donc les Ids disponibles. Le problème c'est qu'alors il faudrait modifier toutes les requêtes SQL sur cette table pour qu'elles n'intègrent pas les client marqués comme étant supprimés.

Quelque soit la solution, il faudra bien entendu tenir compte de la possibilité d'accès concurrentiels, à moins d'être dans le cas d'une application mono-utilisateur.

Bref, il faut vraiment en avoir besoin pour chercher à implémenter un tel mécanisme.

Mais je suivrai cette conversation avec intéret pour le cas ou elle aboutirait à une idée béton.

Bon courage.

En quoi ma requête réponds à la problématique ? C'est tout simple, l'idée est de réutiliser les id des lignes supprimées d'une table. Ma requête renvoie le prochain id utilisable pour la table en question en tenant compte des id qui ont été supprimés.
Concernant ta remarque à propos des 32bits, voire 64bits, sache qu'il est parfois nécessaire d'inter-opérer avec des systèmes beaucoup plus anciens qui par exemple ne savent pas gérer des id sur 32bits. Il faut donc économiser les id.

Mais ne risques que ton pas d'augmenter le temps d'accés à la base de données ?
Ne serait ce pas mieux alors de passer par une procédure stockée ?

La vraie question, encore une fois, est de savoir si il y a un besoin fonctionnel à procéder de la sorte. Je n'en suis absolument pas convaincu. (et apparement si j'en juge par le poste supra, je ne suis pas le seul).

SaumonAgile, j'ai réussi à faire fonctionner ta requête. C'est mon copier / coller qui n'était pas bon, je ne l'avais pas bien récupérée.

J'ai fait des tests sur 100 000 enregistrements. Les performances sont au rendez-vous, même avec des trous en fin de table ou disséminés un peu partout.

Je sens que je vais étudier la question plus en profondeur, je n'y avais jamais pensé car je n'ai jamais été confronté à ce besoin. C'est vraiment une requête intéressante à se mettre de coté pour le cas ou.

Merci encore.

Citation:

---

Envoyé par Bluedeep

La vraie question, encore une fois, est de savoir si il y a un besoin fonctionnel à procéder de la sorte. Je n'en suis absolument pas convaincu. (et apparement si j'en juge par le poste supra, je ne suis pas le seul).

---

Idem. L'intérêt quand on a un compteur, c'est quand même d'avoir automatiquement des valeurs uniques dont on se fiche royalement du sens (des bonnes clefs primaires quoi). Qu'il y ait des trous, on s'en fout.
S'il ne doit pas y en avoir, il faudrait voir l'intérêt d'avoir ça en clef primaire.

D'autant que si on se met à insérer des valeurs en bouchant les trous, on insère des valeurs un peu n'importe où dans l'index, d'où potentiel de page splits en cascade bien plus grand.

Et si on passe par des requêtes 'exotiques' pour boucher les trous, en plus de ralentir les performances, il faut tenir compte des accès concurrents (que la transaction soit bien isolée pour que 2 personnes ne puissent pas boucher le même trou, ce serait ballot)


De manière générale, en tout cas côté SQLServer, si on a un champ IDENTITY sur une table avec *beaucoup* d'activité, on planifie un job de maintenance de temps en temps pour resserrer les numéros, en se reposant sur les contraintes d'intégrité pour faire les mises à jour en cascade. Cela dit, le 'de temps en temps' est très large.

En ce moment j'ai une table qui se prend grosso modo 2 millions de suppressions et 2 millions d'insertions tous les jours, les ids commencent à 1, ça fait pas loin de 3 ans avant d'être à court d'id. Donc un petit job qui tourne une fois par an, genre quelque part entre noël et le jour de l'an, c'est réglé.

Et si cette histoire de bouchage de trou est purement esthétique, alors on oublie. C'est fait pour être pratique, simple, fiable et séquentiel. Pas pour être esthétique.