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

Langage SQL Discussion :

Auto incrémentation en cas de suppression d'enregistrement


Sujet :

Langage SQL

  1. #1
    Membre du Club
    Homme Profil pro
    Autre
    Inscrit en
    mars 2021
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Autre

    Informations forums :
    Inscription : mars 2021
    Messages : 95
    Points : 63
    Points
    63
    Par défaut 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

  2. #2
    Expert éminent sénior
    Homme Profil pro
    Responsable Données
    Inscrit en
    janvier 2009
    Messages
    4 960
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable Données

    Informations forums :
    Inscription : janvier 2009
    Messages : 4 960
    Points : 12 060
    Points
    12 060
    Par défaut
    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.

  3. #3
    Membre régulier
    Profil pro
    Inscrit en
    juin 2004
    Messages
    347
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2004
    Messages : 347
    Points : 88
    Points
    88
    Par défaut
    Citation Envoyé par tatayo Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
     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.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 292
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 21 292
    Points : 50 996
    Points
    50 996
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Nerva Voir le message
    Si cet ID représente la numérotation des factures, ça a de l'importance. On peut toujours faire un truc du genre :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
     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 +
    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/ * * * * *

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    8 976
    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 : 8 976
    Points : 33 563
    Points
    33 563
    Billets dans le blog
    3
    Par défaut
    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 !

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    21 292
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 21 292
    Points : 50 996
    Points
    50 996
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par escartefigue Voir le message
    ...
    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 +
    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/ * * * * *

  7. #7
    Membre du Club
    Homme Profil pro
    Autre
    Inscrit en
    mars 2021
    Messages
    95
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Mayenne (Pays de la Loire)

    Informations professionnelles :
    Activité : Autre

    Informations forums :
    Inscription : mars 2021
    Messages : 95
    Points : 63
    Points
    63
    Par défaut
    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

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    juin 2004
    Messages
    347
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2004
    Messages : 347
    Points : 88
    Points
    88
    Par défaut
    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) .

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 12/05/2009, 12h05
  2. Réponses: 1
    Dernier message: 10/10/2008, 14h56
  3. Champs auto incrémenté et suppression de tuples
    Par Didine981 dans le forum SQL Procédural
    Réponses: 3
    Dernier message: 11/04/2007, 14h38
  4. Réponses: 3
    Dernier message: 15/02/2007, 13h02
  5. Réponses: 6
    Dernier message: 30/08/2006, 12h54

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