IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement SQL Server Discussion :

Auto-incrément vs table de clés


Sujet :

Développement SQL Server

  1. #1
    Membre du Club
    Profil pro
    Inscrit en
    Février 2009
    Messages
    75
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 75
    Points : 42
    Points
    42
    Par défaut 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

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 778
    Points
    30 778
    Par défaut
    Citation Envoyé par gadsweb Voir le message
    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é.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 088
    Points : 38 393
    Points
    38 393
    Billets dans le blog
    9
    Par défaut
    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

  4. #4
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Bonjour,

    En complément d'Escartefigue :

    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.

    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.

    @++

  5. #5
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 447
    Points
    52 447
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par gadsweb Voir le message
    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. [WD14] Auto-incrémentation sur table mémoire
    Par BENKOUIDER dans le forum WinDev
    Réponses: 1
    Dernier message: 02/08/2009, 14h17
  2. [Oracle] Auto-incrémentation id table
    Par teufa14 dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 15/01/2008, 16h30
  3. Réponses: 5
    Dernier message: 09/03/2007, 20h39
  4. [TABLE] auto-incrément corrompu
    Par metheorn dans le forum Access
    Réponses: 2
    Dernier message: 29/05/2006, 13h10
  5. Compactage de tables Paradox avec auto-incrément
    Par Unusual_FL dans le forum Bases de données
    Réponses: 2
    Dernier message: 22/09/2004, 16h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo