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 ?
Version imprimable
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.
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.Citation:
Envoyé par Bluedeep
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.