Auto-incrément vs table de clés

Version imprimable

09/07/2015, 21h55
gadsweb

Auto-incrément vs table de clés

Bonsoir à tous,

J'ai appris à mes dépens récemment que lors de l'auto-incrément d'une colonne, non seulement il pouvait sauter des index, mais également revenir en arrière.
Ce qui pose problème par exemple pour chercher le dernier index inséré (via select max) selon des critères dans la clause where.
Je travaille donc dorénavant avec une table de clés qui me garantit la successivité et l'ordre des index.

Mais alors, à quoi sert l'auto-increment si ce n'est pas fiable ? :-(

C'est peut-être bête comme question, mais là il y a truc qui m'échappe.

Merci de vos avis éclairés
10/07/2015, 09h31
al1_24
Citation:

Envoyé par gadsweb

Mais alors, à quoi sert l'auto-increment si ce n'est pas fiable ?
- Garantir l'unicité de l'identifiant
- S'auto-incrémenter sans action extérieure (ça parait évident mais ça va mieux en le disant)
Pour connaître le dernier inséré, il vaudrait mieux se baser sur un timestamp... mais avec le risque de doublons en cas de mise à jour simultanée. Doublon qui ne sera pas rencontré par l'identifiant auto-incrémenté.;)
10/07/2015, 09h40
escartefigue

Les identity column sont fiables, il n'y a pas de bugs, il y a juste plusieurs façons de fonctionner qui sont paramétrables (valeur initiale, valeur d'incrément, affectation systématique ou pas...)
A noter que l'incrément peut très bien être un décrément : on peut partir de 999999999... et diminuer la valeur
Quand une ligne est supprimée, il est possible de récupérer la valeur de l'identifiant rendu disponible, ce fonctionnement est normal.

Donc, pour connaitre l'enregistrement le plus récent, ce n'est pas une bonne idée de tester la valeur d'une identity column, il faut utiliser les colonnes d'horodatage sachant qu'il peut y avoir des doublons (même avec un timestamp)

La solution d'une table de chrono gérée manuellement est possible aussi, c'est alors à l'application d'en garantir le bon fonctionnement
10/07/2015, 10h52
elsuket

Bonjour,

En complément d'Escartefigue :

Citation:

Je travaille donc dorénavant avec une table de clés qui me garantit la successivité et l'ordre des index.

S'il vous est absolument nécessaire que les valeurs générées soient successives, alors effectivement ajouter la propriété d'auto-incrémentation à une colonne ne répond pas à cette problématique.
Si un INSERT s'exécute correctement, mais que la transaction échoue, alors l'INSERT est annulé, mais le compteur n'est pas décrémenté : cela génèrerait une surchage en verrouillage qui est inutile, puisque le but de cette propriété est de donner un identifiant irréductible et unique.

Par contraste, la table de clé fonctionne, puisque vous réalisez un UPDATE de la valeur. Si la transaction échoue, alors le compteur reste à la valeur où il était au début de la transaction.

Citation:

Ce qui pose problème par exemple pour chercher le dernier index inséré (via select max) selon des critères dans la clause where.

le SELECT MAX(PK_column) pour trouver la dernière valeur insérée la colonne qui sert de clé primaire est une mauvaise idée, puisqu'alors on doit scanner l'index sous-jacent.
La fonction SCOPE_IDENTITY() et IDENT_CURRENT() servent cet office.

@++ ;)
10/07/2015, 12h26
SQLpro

Citation:

Envoyé par gadsweb

Bonsoir à tous,

J'ai appris à mes dépens récemment que lors de l'auto-incrément d'une colonne, non seulement il pouvait sauter des index, mais également revenir en arrière.
Ce qui pose problème par exemple pour chercher le dernier index inséré (via select max) selon des critères dans la clause where.
Je travaille donc dorénavant avec une table de clés qui me garantit la successivité et l'ordre des index.

Mais alors, à quoi sert l'auto-increment si ce n'est pas fiable ? :-(

C'est peut-être bête comme question, mais là il y a truc qui m'échappe.

Merci de vos avis éclairés

L'auto incrément n'a pas vocation à servir d'unicité. Seules, les contraintes UNIQUE et PRIMARY KEY le garantisse. Il n'a pas non plus besoin d'être continu.
Vous pouvez effectivement "resetter" la valeur de IDENTITY ou forcer des valeurs...
Ceci est le comportement normal de tous les SGBDR sans exceptions.

La Loi oblige pour les n° de facture :

"
La numérotation des factures est représentée par un numéro unique basé sur une séquence chronologique continue, sans rupture. Il ne doit pas être possible d'émettre des factures à posteriori. Deux factures ne peuvent pas avoir le même numéro.

La numérotation peut être établie par séries distinctes, avec un système de numérotation propre à chaque série, si les conditions d'exercice le justifient (plusieurs sites de facturation, différentes catégories de clients pour lesquels les règles de facturation ne sont pas identiques, sous-traitance de facturation...).

Il est également possible d'émettre des factures utilisant par exemple un préfixe par année (2014-XX) ou par année et mois (2014-01-XX), ce qui facilite l'archivage.
"
Comme indiqué, vous pouvez avoir plusieurs fois les mêmes numéro sur des séries distinctes. Par exemple 2014-1 et 22015-1 (1 étant le numéro de facture) d'ou l'importance de pourvoir faire un RAZ de l'auto incrément.

C'est à vous de veiller à ce que tous les n° soient utilisés. Par exemple en cas d'annulation de transaction, un n° peut être grillé. Il vous suffit alors de recréer cette facture avec le numéro grillé et de spécifier qu'elle est sans objet du fit d'une erreur !

C'est pour cela que vous pouvez aussi forcer des valeurs !

Tout ceci est la marche normale d'un commerce... Avec le papier c'était la même chose. Si la personne se trompait en éditant la facture, elle la barrait et la laissait dans le facturier !!!

A +