Version imprimable
Bonjour,
Je m'interroge sur l'utilité des clefs autoincrementes...
Vaut-il mieux les utiliser ou juste faire un "select max" manuellement et ajouter un a la cle max...
Comment ca se passe pour les champs supprimes ? Est-ce qu'en cas d'autoincrementation le sgbd propose de recuperer des cles plus utilises ou si on choisit une cle manuellement est-ce d'usage de recuperer ces cles aussi manuellement ?
Merci !
Le select max va avoir tendance à coûter de + en + cher en temps d'exécution, à mesure que la table grossit.Citation:
Envoyé par okparanoid
Les clés auto-incrémentées sont souvent utilisées quand on ne s'intéresse qu'à un identifiant discriminant dont on veut s'épargner la gestion. Le SGBS garantit l'unicité de l'identifiant, et c'est bien tout ce qu'on recherche.
Quelle importance s'il y a des trous dans la séquence, puisque l'unicité des identifiants (présents en base et à venir) est respectée ?Citation:
Comment ca se passe pour les champs supprimes ? Est-ce qu'en cas d'autoincrementation le sgbd propose de recuperer des cles plus utilises ou si on choisit une cle manuellement est-ce d'usage de recuperer ces cles aussi manuellement ?
Ok, mais en faite le probleme que me pose l'autoincrementation et qu'il ne permet pas de savoir l'index du champ que l'on vient d'ajouter, a moins que je me trompe ?
La solution serait donc de reseter la feuille de saisie pour obliger l'utilisateur a recharger le tuple via une interface utilisant un tquery + dbgrid s'il desire l'editer.
Comment tu fais dans ce genre de cas ?
Merci !
Connaître le dernier identifiant auto-incrémenté est une autre histoire :lol:
Certains SGBD proposent des fonctions toutes faites pour cela, comme le last_insert_id de MySQL, ou l'interrogation du trigger sous Interbase/firebird.
Ce n'est donc pas un problème, et c'est effectivement nécessaire dans le cas ou cet identifiant sert de Foreign Key dans une autre table.