Je sauvegarde une seule chaîne sur une table, elle doit être unique, je vais vérifier qu'elle n'existe pas déjà avant de l'enregistrer. Il n'y a pas d'autres domaines. Puis-je simplement avoir une seule table de colonnes avec la chaîne comme clé primaire ou devrais-je aussi avoir une colonne identifiant unique ID? Pourquoi dans les deux cas?Une seule colonne de chaînes ou deux colonnes?
Si votre chaîne est unique (et sera toujours unique), alors c'est bien d'avoir cela comme seule colonne et clé primaire.
La seule raison pour laquelle j'utiliser une pièce d'identité est séparée si l'
J'appliquerais le principe YAGNI à ces deux situations et je m'en soucierai quand cela arrivera. En outre, avec les applications de base de données, il vaut mieux ne pas "vérifier qu'il n'existe pas avant de l'enregistrer". J'ai tendance à simplement essayer de le sauvegarder et d'attraper l'erreur si elle existe déjà. Puisque c'est une clé primaire (ou une contrainte unique), cela fonctionnera.
La vérification de l'existence puis l'insertion conduit souvent à des conditions de course.
La chaîne peut-elle changer? Quelle est la longueur de la chaîne (important si d'autres tables vont l'utiliser comme clé étrangère)?
Généralement, si la valeur peut changer, ou si vous avez besoin d'autres tables à associer, je recommande d'avoir un champ d'identification désigné.
Si les chaînes sont toujours uniques, utilisez une seule colonne. Pour économiser de l'espace (bien que ce soit peut-être petit), vous n'avez pas besoin d'une autre colonne d'ID. Ajoutez une contrainte d'ID unique à la colonne pour forcer des valeurs uniques uniquement.
C'est à vous si vous voulez faire une vérification pour voir si la valeur existe. Bien que l'avoir toujours à travers une erreur d'identification unique n'est pas un moyen approprié de vérifier si la valeur existe déjà dans la table. Enregistrez la gestion des erreurs pour les erreurs réelles et effectuez la vérification manuellement. Les exceptions peuvent avoir un faible impact sur les performances et doivent être conservées pour de vraies exceptions de programme, pas la norme.
Cependant, si pour une raison quelconque, la chaîne va être référencée dans une autre colonne, je créerais un champ ID. Si la longueur de la chaîne est de 32 caractères, il faudra 32 octets d'espace (en supposant ASCII) par enregistrement. Un int de 32 bits en tant que clé primaire ne prendra que 4 octets (32/8 = 4). Donc, si vous faites référence à la chaîne dans une autre table, vous économiserez de l'espace en utilisant un ID entier. En outre, si vous utilisez un ID entier pour la clé primaire, vous pouvez envisager de regrouper l'index par la chaîne (si vous effectuez beaucoup de recherches par la chaîne plutôt que par l'ID). Regrouper par la chaîne au lieu de la clé primaire peut faire beaucoup pour la performance dans ce cas. Etes-vous sûr que cette chaîne sera unique?
personne ne sera jamais capable de le changer? Si c'est le cas, ça va. de toute façon, il suffit d'utiliser un ID
+1 pour s'appuyer sur une contrainte unique plutôt que de coder une vérification manuelle. – APC