Le scénario implique une table MySQL où la colonne id sert de champ d'incrémentation automatique pour le visuel commodité, tandis que la colonne memberid agit comme la clé unique réelle. Cependant, la tentative de définition de la table avec PRIMARY KEY (memberid) entraîne une erreur (1075) indiquant qu'il ne peut y avoir qu'une seule colonne automatique et qu'il doit s'agir d'une clé.
Pour résoudre le problème, il est possible d'avoir une colonne auto-incrémentée qui n'est pas la CLÉ PRIMAIRE, à condition qu'un index (clé) y soit défini. Voici la définition de la table modifiée :
<code class="sql">CREATE TABLE members ( id int(11) UNSIGNED NOT NULL AUTO_INCREMENT, memberid VARCHAR(30) NOT NULL, `time` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, firstname VARCHAR(50) NULL, lastname VARCHAR(50) NULL, PRIMARY KEY (memberid), KEY (id) # or: UNIQUE KEY (id) ) ENGINE = MYISAM;</code>
En ajoutant un index KEY ou UNIQUE KEY sur la colonne id, la fonctionnalité d'auto-incrémentation est maintenue tandis que la colonne memberid devient la clé primaire, permettant des requêtes efficaces basées sur le valeur memberid.
Le meilleur choix dépend de l'importance relative des performances et de l'espace disque. Si les performances sont primordiales, le maintien de la colonne d'identifiant à incrémentation automatique et l'utilisation d'un index sur l'identifiant de membre offrent un équilibre :
Cependant, si l'espace disque est un problème important, envisagez de supprimer complètement la colonne ID et de vous fier à la colonne MemberID comme clé primaire et auto. -champ incrémental. Cette approche sacrifie certaines performances au profit d'une meilleure utilisation de l'espace. En fin de compte, le choix entre performances et espace dépend des exigences spécifiques de l'application.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!