Discussion :

[Germaris]

Bonjour !

Suite à l'élimination des doublons d'une table, la colonne ID (AUTO-INCREMENT) présente de nombreuses entrées vides au-dessus de l'index, par exemple, 49930.
Comment réattribuer les numéros des entrées non-vides à partir de 49930 de façon à ne plus avoir d'entrées vides ?

Merci d'avance pour votre aide !

[CinePhil]

On ne réutilise JAMAIS les identifiants auto-incrémentés supprimés !
On ne les modifie JAMAIS !

Un identifiant est une clé technique pour le SGBD qui n'a aucune signification. Par contre, comme cet identifiant est potentiellement utilisé comme clé étrangère dans d'autres tables, changer l'identifiant demande de modifier les clés étrangères et là ça peut foutre la pagaille dans les données si le mécanisme de cascade n'est pas programmé partout et qu'on s'aventure à le faire à la main.

Bref, NE LE FAIS PAS !

[Germaris]

Merci pour ta réponse !

Je sais, mais toutes mes tables sont MyISAM et je n'utilise aucune clé étrangère...

[CinePhil]

Et bien justement, c'est encore pire parce que tu ne peux pas avoir de mécanisme automatique qui mette à jour les tables référencées.

Ou alors c'est encore pire que ce que je pense et tu n'utilises pas tes identifiants comme référence dans les tables associées ?

[Germaris]

Ouh la la, faut que je change ma couche !!!

D'abord, je me méfie des automatismes comme de la peste.
Je ne crois qu'aux actions que je déclenche en pleine connaissance de cause.

Je vais te donner un exemple.
J'ai une table principale qui répertorie toutes les personnes que mon annuaire se doit de mentionner.
Dans cette table, chaque personne mentionnée est munie de tous les renseignements nécessaires la concernant.

J'ai, d'autre part, une table secondaire pour les utilisateurs enregistrés.

Si j'avais un automatisme liant les deux, ce serait le foutoir pour plusieurs raisons :
1 - Un enregistré non répertorié verrait son dossier créé automatiquement dans la table principale sans aucun contrôle sur l'authenticité des données introduites lors de l'enregistrement. L'admin se doit de vérifier ces données personnelles avant d'admettre un nouvel utilisateur.
2 - Quid des homonymes existant parfois au sein d'une même école et d'une même année de promotion ?!!! Aucun automatisme ne pourrait décider du choix.
3 - Les identifiants de ces deux tables sont toujours différents.

Ces raisons majeures (il y en a d'autres) font que jamais je n'utilise l'identifiant dans mes scripts de lecture et d'écriture.

Je ne cours donc, à mon humble avis aucun danger à modifier la colonne ID de ma table principale.

[CinePhil]

A mon avis tu utilises surtout un SGBD complètement de travers !

Les identifiants auto-incrémentés sont justement là pour différencier les jumeaux parfaits.

Si j'ai bien compris ce que tu as écrit, tu as des personnes dont certaines sont aussi des utilisateurs ?

Règle de gestion :
Un utilisateur est une personne et une personne peut être un utilisateur.

Cette règle est typiquement celle d'un héritage de données.

MCD :
utilisateur -(1,1)----être----0,1- personne

Tables :
te_personne_prs (prs_id, prs_nom, prs_prenom, prs_date_naissance, [colonnes communes à toutes les personnes])
th_utilisateur_uti (uti_id_personne, uti_login, uti_mot_passe, [colonnes spécifiques aux utilisateurs])

prs_id est un identifiant auto-incrémenté, clé primaire de la table te_personne_prs.
uti_id_personne est à la fois une clé étrangère référençant l'identifiant de la personne qui est aussi un utilisateur et la clé primaire de la table th_utilisateur_uti. Avec des tables en InnoDB et une contrainte de clé étrangère ON DELETE CASCADE sur la colonne uti_id_personne, quand tu supprimes la personne de la table te_personne_prs, cela supprime automatiquement l'utilisateur correspondant dans la table th_utilisateur_uti. Bien sûr, l'inverse n'est pas vrai ; supprimer l'utilisateur ne supprime pas automatiquement la personne.

Bref, il ne faut pas zapper l'étape "modélisation" !