Prochaine valeur de la clée primaire

Prochaine valeur de la clée primaire - SQL/NoSQL - Programmation

Marsh Posté le 21-07-2008 à 20:02:46    

Bonjour,
Est-il possible d'obtenir d'une table la valeur de la clée primaire du prochain enregistrement ?
Ce n'est pas n+1 si on supprime des enregistrements avant.

Reply

Marsh Posté le 21-07-2008 à 20:02:46   

Reply

Marsh Posté le 21-07-2008 à 23:05:19    

Bonsoir,
 
Tout dépend si ta clé primaire est une valeur numérique ou non. Dans le cas d'un valeur numérique c'est n+1. n étant la dernière valeur. Les clés suprimés sont "perdus"...

Reply

Marsh Posté le 22-07-2008 à 11:31:02    

cvb a écrit :

Bonsoir,
 
Tout dépend si ta clé primaire est une valeur numérique ou non. Dans le cas d'un valeur numérique c'est n+1. n étant la dernière valeur. Les clés suprimés sont "perdus"...


ouh là malheureux, faut pas affirmer des trucs comme ça :o
 
tout dépend du système utilisé pour générer les ID : type de données "numauto", séquence, traîtement manuel par trigger, etc.
 
selon les SGBD, les types de données "numauto" n'existent parfois pas, et parfois bouchent les trous ou non, et pas toujours de façon linéaire (genre il va commencer à boucher les trous une centaine d'insertions après la suppression). bref, y'a AUCUNE règle qui soit absolue, et surtout, ce qui est vrai dans une build particulière du SGBD ne le sera pas forcément dans la suivante. en effet, un numauto est un type 100% géré par le système, et un ID ne doit par définition pas avoir de signification fonctionnelle, donc se soucier de sa valeur n'a pas de sens d'un point de vue analyse.
 
pour les séquences, y'a pas de bouchage de trous, par contre il y a un pas (l'incrément n'est pas forcément de +1, il peut être de -24 par exemple) et les séquences peuvent boucler (et dans ce cas, ne bouchent pas les trous, elle génèrent des valeurs en repartant de 0 comme la première fois)
 
le traîtement manuel est donc le seul où tu peux à coup sûr prévoir le comportement, et c'est dans le seul cas qu'il faudra tenter de récupérer la prochaine valeur. ceci dit, c'est suicidaire dans la mesure où si deux personnes utilisent l'application en même temps, elles croiront toutes les deux pouvoir créer le même ID à un instant T, ce qui est faux.

Reply

Marsh Posté le 22-07-2008 à 17:19:56    

MagicBuzz a écrit :


ouh là malheureux, faut pas affirmer des trucs comme ça :o
 
tout dépend du système utilisé pour générer les ID : type de données "numauto", séquence, traîtement manuel par trigger, etc.
 
selon les SGBD, les types de données "numauto" n'existent parfois pas, et parfois bouchent les trous ou non, et pas toujours de façon linéaire (genre il va commencer à boucher les trous une centaine d'insertions après la suppression). bref, y'a AUCUNE règle qui soit absolue, et surtout, ce qui est vrai dans une build particulière du SGBD ne le sera pas forcément dans la suivante. en effet, un numauto est un type 100% géré par le système, et un ID ne doit par définition pas avoir de signification fonctionnelle, donc se soucier de sa valeur n'a pas de sens d'un point de vue analyse.
 
pour les séquences, y'a pas de bouchage de trous, par contre il y a un pas (l'incrément n'est pas forcément de +1, il peut être de -24 par exemple) et les séquences peuvent boucler (et dans ce cas, ne bouchent pas les trous, elle génèrent des valeurs en repartant de 0 comme la première fois)
 
le traîtement manuel est donc le seul où tu peux à coup sûr prévoir le comportement, et c'est dans le seul cas qu'il faudra tenter de récupérer la prochaine valeur. ceci dit, c'est suicidaire dans la mesure où si deux personnes utilisent l'application en même temps, elles croiront toutes les deux pouvoir créer le même ID à un instant T, ce qui est faux.


 
C'est bien pour ça que j'ai précisé valeur numérique  ;)  
j'ai oublié numéro auto, pour être  tout à fait exact :)

Reply

Marsh Posté le 22-07-2008 à 19:23:58    

ouais, en fait le id est en autoincrément de MySQL et je souhaitais insérer un enregistrement et inclure dans un autre champ l'id de l'enregistrement lui même.
Mais est-ce possible ?

Reply

Marsh Posté le 22-07-2008 à 19:40:49    

non.
 
(et je vois pas du tout à quoi ça va te servir)
 
au pire, t'as une fonction qui permet de récupérer le dernier ID. donc tu fais un update dans la foulée.
 
ou tu peux tenter avec un trigger, mais c'est loin d'être sûr que la valeur du numauto soit déjà connue au moment de l'insertion.

Reply

Marsh Posté le 22-07-2008 à 20:26:46    

ça me sert à renommer un fichier et d'y inclure son id dans le nom du fichier, de cette manière, avec le fichier seul, je peux connaître sa référence !
trigger, j'ai regardé, mais il semble pas, c'est new sur MySQL

Reply

Marsh Posté le 23-07-2008 à 00:10:27    

nan mais surtout, si t'as déjà une colone ID, à quoi ça sert d'avoir une seconde colonne qui prend la même valeur ?

Reply

Marsh Posté le 23-07-2008 à 09:52:11    

c'est pas une seconde colonne, la seconde colonne contient le nom d'un fichier et ce nom est composé du N° de catégorie, N° ID et autre.

Reply

Marsh Posté le 23-07-2008 à 10:36:06    

c'est donc un champ calculé, il n'a pas à être stocké

Reply

Marsh Posté le 23-07-2008 à 10:36:06   

Reply

Marsh Posté le 23-07-2008 à 12:01:57    

oui, il y a redondance, mais je préfère par sécurité perso.

Reply

Marsh Posté le 24-07-2008 à 13:34:38    

oui
 
mais non

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed