Discussion :

[Petsman]

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

[Invité]

En quoi c'est un problème ?

[escartefigue]

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

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

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

[François DORIN]

Bonjour,

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.

[escartefigue]

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

[François DORIN]

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 !

[taibag]

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.