1. #1
    Membre à l'essai
    Inscrit en
    juillet 2007
    Messages
    23
    Détails du profil
    Informations forums :
    Inscription : juillet 2007
    Messages : 23
    Points : 18
    Points
    18

    Par défaut select* affiche les primary keys dans le desordre

    bonjour

    je dispose d'une table ayant pour première colonne le numéro de série du produit a enregistrer
    cette colonne est "primary key" car il ne doit y avoir qu'une seule ligne par numéro. toutefois il ne s’auto incrémente pas et doit être entré lors de l'insertion de la ligne.

    voir image ci dessous des paramétrés de cette colonne.

    mon problème:
    c'est OK quand je fais un insert into, ligne par ligne, manuellement, un select * de base me les affichera dans l'ordre croissant, quelque soit l'ordre des numéros entres
    par contre, si mes requêtes d'insertion sont envoyées en grand nombre, depuis un programme (une centaine a la fois), le select * de base me les mettra dans le désordre, a tout jamais.
    comme si la primary key n'etait pas prise en compte pour classer les donnée. je suis donc obligé de faire un "order by" pour tout remettre en ordre.

    remarque: lorsque je supprime une de ces lignes dans le désordre (delete) et que je la recrée (insert into), celle ci réapparait EXACTEMENT au meme endroit. comme si le classement était pre-assigné par une colonne cachée d'ID plutôt que la primary key

    avez vous une solution pour que le vrai ID utilisé pour le classement par défaut sans ORDER BY suive bien la primary key

    merci d'avance

    Nom : Sans titre.png
Affichages : 131
Taille : 32,5 Ko

  2. #2
    Membre chevronné
    Femme Profil pro
    dba
    Inscrit en
    juillet 2007
    Messages
    3 710
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Canada

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : juillet 2007
    Messages : 3 710
    Points : 1 832
    Points
    1 832

    Par défaut

    En quoi c'est un problème ?

  3. #3
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 968
    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 : 2 968
    Points : 6 530
    Points
    6 530
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par Petsman Voir le message
    je dispose d'une table ayant pour première colonne le numéro de série du produit a enregistrer
    cette colonne est "primary key" car il ne doit y avoir qu'une seule ligne par numéro. toutefois il ne s’auto incrémente pas et doit être entré lors de l'insertion de la ligne.
    Sauf que vous avez défini la colonne en nvarchar, ce qui est une très mauvaise idée concernant une PK !
    Tout ce qui est (n)char/varchar est sensible à la collation
    Tout ce qui est (n)varchar peut provoquer des déplacement physiques de pages de data et d'index, ce qui pénalise les perfs
    De plus c'est plus encombrant que de l'intéger
    Ensuite c'est tentant d'y mettre une valeur fonctionnelle, donc instable, donc à proscrire en PK
    Et enfin, pour un incrément c'est pas top


    Citation Envoyé par Petsman Voir le message
    mon problème:
    c'est OK quand je fais un insert into, ligne par ligne, manuellement, un select * de base me les affichera dans l'ordre croissant, quelque soit l'ordre des numéros entres
    par contre, si mes requêtes d'insertion sont envoyées en grand nombre, depuis un programme (une centaine a la fois), le select * de base me les mettra dans le désordre, a tout jamais.
    comme si la primary key n'etait pas prise en compte pour classer les donnée. je suis donc obligé de faire un "order by" pour tout remettre en ordre.
    C'est tout à fait normal, seule la clause ORDER BY permet d'obtenir un séquencement des lignes restituées

    Citation Envoyé par Petsman Voir le message
    avez vous une solution pour que le vrai ID utilisé pour le classement par défaut sans ORDER BY suive bien la primary key
    un classement par défaut, ça n'existe pas, ça n'a aucun sens dans un modèle relationnel !
    Créez un ID de type integer, définissez le comme calculé par la BDD et ajoutez une clause ORDER BY, c'est la seule solution

  4. #4
    Rédacteur/Modérateur

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

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

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 374
    Points : 4 689
    Points
    4 689
    Billets dans le blog
    5

    Par défaut

    Bonjour,

    Citation Envoyé par Petsman Voir le message
    avez vous une solution pour que le vrai ID utilisé pour le classement par défaut sans ORDER BY suive bien la primary key
    On tombe dans un des écueil classique concernant les bases de données. Il faut se rappeler une chose très importante : les bases de données relationnelles sont ensemblistes. Elles sont faites pour cela. Une notion d'ordre n'a de sens que lors de la visualisation des données.

    A noter d'ailleurs qu'exécuter deux fois de suite la même requête (sans ORDER BY) ne garantie en rien que les résultats affichés le seront dans le même ordre.

    La seule chose à faire dans votre cas, c'est donc d'utiliser la clause ORDER BY.

    Maintenant, à la vue de votre question et de la modélisation (une clé primaire en NVARCHAR !), je ne peux que constater votre méconnaissance du fonctionnement d'un SGBD (ce n'est pas une injure, on a tous été débutant avant de devenir expert) et vous invite donc à approfondir le sujet. Cela vous permettra de bien mieux comprendre ce que vous faites et vous éviter de nombreux problèmes par la suite.
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  5. #5
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    2 968
    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 : 2 968
    Points : 6 530
    Points
    6 530
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par François DORIN Voir le message
    On tombe dans un des écueil classique concernant les bases de données. Il faut se rappeler une chose très importante : les bases de données sont ensemblistes. Elles sont faites pour cela. Une notion d'ordre n'a de sens que lors de la visualisation des données.
    Oui à une correction près : les bases de données relationnelles sont ensemblistes.

    Les plus anciens se souviennent que les bases de données hiérarchiques et les bases de données réseau ne l'étaient pas, dans ces bases de données d'antan, la notion d'ordre par défaut avait un sens, c'était même ce qui permettait de naviguer dans les enregistrements (on ne parlait pas de ligne à cette époque, et pour cause !).

    Je referme cette parenthèse paléolithique

  6. #6
    Rédacteur/Modérateur

    Avatar de François DORIN
    Homme Profil pro
    Consultant informatique
    Inscrit en
    juillet 2016
    Messages
    1 374
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Charente Maritime (Poitou Charente)

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

    Informations forums :
    Inscription : juillet 2016
    Messages : 1 374
    Points : 4 689
    Points
    4 689
    Billets dans le blog
    5

    Par défaut

    Citation Envoyé par escartefigue Voir le message
    Je referme cette parenthèse paléolithique
    Tellement paléolithique que je viens de modifier mon post initial ! Autant être précis jusqu'au bout, même si le contexte ne laissait que peu de doute à ce sujet !
    François DORIN
    Consultant informatique : conception, modélisation, développement (C#/.Net et SQL Server)
    Site internet | Profils Viadéo & LinkedIn
    ---------
    Page de cours : fdorin.developpez.com
    ---------
    N'oubliez pas de consulter la FAQ C# ainsi que les cours et tutoriels

  7. #7
    Membre averti
    Avatar de taibag
    Homme Profil pro
    Étudiant
    Inscrit en
    septembre 2013
    Messages
    212
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Inde

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

    Informations forums :
    Inscription : septembre 2013
    Messages : 212
    Points : 353
    Points
    353
    Billets dans le blog
    1

    Par défaut

    Bonjour

    L'un des points les plus importants à comprendre au sujet de SQL est qu'une table n'a pas de garantie d’être ordonnée, car une table au relational model est censée représenter un ensemble , et un ensemble n'a pas d'ordre.
    मैं एक छात्र हूँ |

Discussions similaires

  1. Question sur les primaries key
    Par izioto dans le forum Langage SQL
    Réponses: 3
    Dernier message: 21/11/2006, 13h22
  2. Réponses: 3
    Dernier message: 11/09/2006, 13h03
  3. Réponses: 4
    Dernier message: 04/09/2006, 15h24
  4. afficher les tables invisible dans acces
    Par zidenne dans le forum Access
    Réponses: 4
    Dernier message: 08/07/2006, 22h43
  5. comment intérroger les Primary key par req SQL ?
    Par nanou9999 dans le forum MS SQL-Server
    Réponses: 2
    Dernier message: 03/03/2006, 10h22

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