Par exemple, si j'ai un utilisateur de table, je veux stocker le sexe ou le sexe, je vais ajouter une colonne comme vaut vraiment la peine d'utiliser un entier, puis de la cartographier dans mon langage de programmation préféré?
Comme Y a-t-il une raison de performance de faire ça?
ou pourrais-je utiliser un variole en toute sécurité qui plus signification avec "femme" ou "mâle" presque comme j'utilisais mysql EDIT : I ICI et là que c'est parfois meilleur, parfois cela n'a pas d'importance, alors je cherche plus de référence ou quelque chose sur un "c'est mieux" répondre.
Je veux dire que je pense qu'utiliser Varchar est en fait plus de sens que d'un entier, et j'utiliserais un entier uniquement si la performance est supérieure à 0,3% ou quelque chose. sexe .
1 => 'mâle' et 2 => 'femelle'
Enum ?
7 Réponses :
Ce sera beaucoup plus rapide que de faire une comparaison de chaîne, si vous faites n'importe quel Exemple: Dites que j'ai Dis maintenant que j'ai Misté Idéalement, sélectionne sur elle. femelle comme une chaîne. Ses 6 caractères de long. Il doit donc faire une comparaison 6 fois pour chaque enregistrement, qui utilise un boîtier strict - il devient plus coûteux de faire de la casse insensible. 123456 comme int. Sa valeur unique, pas 6 à comparer, même si la chaîne lisible humaine est de 6 caractères de 6 caractères. Homme et femelle serait une autre table et votre table aurait un FK à cette table.
L'avantage de stocker comme Quant à la conservation d'un entier, il est un peu obscurcié, mais aussi longtemps que dans la spécification de données et les mappages définis clairement, vous récoltez des avantages d'utiliser les données de manière plus productive dans votre application (en utilisant une cartographie mapper un Il y a bien sûr la voie de stockage des «options» dans une table dédiée et que d'autres champs de table se référennent, mais ce que j'ai trouvé dans de nombreux projets est que cela est loin d'être idéal en termes d'utilisation, à moins de toujours utiliser Types mappables - qui ne sert alors à obscurer les choses un peu plus, potentiellement. varchar est que les données peuvent la plupart de la part de lui-même - cependant, il se termine là et ne se manifeste que dans des requêtes contre les données brutes qui seront généralement faites par un développeur que Connaît le système de toute façon (exposition de la fonctionnalité de requête des données aux utilisateurs ou d'autres utilisateurs d'une couche d'application, ce qui signifie que vous auriez le formater si vous souhaitez, mais que ces données sont correctes, mais envisagez de devoir Constamment analyser!
INTEGER à un Enum est une chose unique et expose un type plus utilisable en termes de termes ou de la logique de branchement, en supprimant une analyse de chaîne.) Il sera également plus efficace que de stocker cordes.
réponse ortétiginale: em> L'erreur rampée dans laquelle j'ai utilisé l'assistant de MySQLworkbench pour créer les tables et avoir oublié Pour modifier le moteur de base de données dans les autres tables et il est fait défaut sur Les résultats corrigés sont les suivants (j'ai supprimé tous mes points de repère précédents Comme ils étaient invalides): p> nouvelle conclusion: strong> si vous utilisez la structure de la table em> pour référence est: p>
Je suggérerais de le stocker dans un char (1) code> en tant que M code> ou f code>
Il est suffisamment expressif pour le but spécifique et la rapidité d'être une comparaison de caractères unique
Tous les Les repères précédents avaient une faille fatale em> celle-laquelle (la char (1) code>) était myisam code> et tous les autres étaient innodb code>. Donc j'ai recréé la base de données avec toutes les tables à l'aide du myisam code> et les résultats gagnent beaucoup plus de sens maintenant. P> Innodb CODE> (j'ai MySQL 5.5) P> tinyint code> est le plus rapide. Mais ma recommandation serait toujours utilisée char (1) code> car il serait plus facile pour les développeurs futurs de comprendre la base de données. P> tinyint code >, ma recommandation serait nommer la colonne ismale code> au lieu de sexe code> et stocke 0 => femelle code> et 1 => mâle Code> rendant ainsi un peu plus facile à comprendre dans la base de données RAW. p> CHAR(1), VARCHAR(6), TINYINT
Résultats intéressants. Sont-ils toujours reproductibles? Également et si vous essayez tinyint ?
@Martinsmith Je suis exécuté cela plus de 10 fois et les résultats sont similaires. J'ai été surpris aussi. Je vais essayer avec un champ TIYint et mettre à jour mes résultats
@Martinsmith j'ai mis à jour mes résultats de référence, avec une table avec tinyint colonne. Toujours Char (1) est le gagnant. J'ai également résumé mes résultats de référence au début de mon post. Regarde. Et les résultats sont cohérents sur plusieurs pistes de référence.
@Martinsmith Les résultats étaient incorrects. J'ai utilisé différents moteurs de stockage pour les tables. S'il vous plaît voir ma réponse mise à jour Il a plus de sens maintenant que tinyint est le plus rapide. Nous faisons tous des erreurs stupides ;-)
Je suis toujours déjà + 1 vous avoir pris le temps de repousser de toute façon que l'OP indique qu'ils veulent connaître le différentiel de performance réel à attendre.
Cela fait du bon compromis que je cherchais un sens et une performance, je pense toujours que nous ne sommes plus que nous ne sommes plus dans les années 80 'et cette optimisation de stockage ne s'applique qu'à une grande base de données, la mine est d'environ 300 000 utilisateurs enregistrés qui est bon mais mai ne suffisez pas pour éviter le sens des raisons de performance. Évidemment, le genre est un cas aussi courant, mais il y a un cas où un peu plus obscur de travailler avec, tel que des statuts ou quelque chose, mais je conviens qu'une table avec un FK serait la meilleure solution, mais pour des données immuables qu'il peut ne pas être nécessaire (sauf pour faire respecter l'intégrité)
Y a-t-il une différence si nous avons utilisé ENUM ('M', 'F') par opposition à caractère (1)?
Entier sont beaucoup plus rapides que de faire une comparaison de chaînes, mais je pense que vous préférez utiliser des caractères 'M' ou 'F'. Si les gens vident la table, ils sauront exactement ce que vous avez voulu et sa meilleure que de maintenir une table de jointure. Sauf si nous allons bientôt courir sur de nouveaux sexes.
@Mikesanchez une telle phrase prophétique. Est-ce que praveen peut-être un prophète?
Cela dépend .. mais généralement oui.
intens prend moins d'espace sur le disque.
int compare plus rapidement
Ints voyagez sur le réseau plus rapidement (plus petit)
Donc, si c'est une ligne seulement, et vous l'interrogeez une fois par jour - vous ne remarquerez jamais, mais en général, vous en bénéficierez.
"Ints comparer plus vite" Je ne suis pas en désaccord mais aucun chiffre spécifique à ce sujet? (s'applique à 3/5 réponses mais ne peut pas être dérangé pour commenter tous)
Eh bien .. Un INT est une valeur unique en mémoire, alors lorsque vous comparez une seule valeur à une autre, c'est une égalité à vérifier ... Les chaînes sont une valeur par caractère, plus des frais généraux pour savoir combien de caractères il y a Dans cette chaîne particulière ... donc plusieurs contrôles.
De plus, les cordes comparent sous des règles de collement qui doivent être plus complexes de toute façon. Comme je l'ai dit, je ne suis pas en désaccord mais les seuls chiffres réels affichés jusqu'à présent n'importe où dans l'une quelconque des réponses indiquent que, pour une raison quelconque de la pratique char (1) Effectue int (Edit: Il suffit de voir la modification à cette réponse qui donne des résultats révisés!)
Si cela est pour un site Web homebrew ou une application qui servira 10 personnes, alors faites ce que vous voulez, la performance ne fera pas une différence.
Si cela est quelque chose réel em> puis sauter rouler votre propre mise en œuvre du genre et suivre les norme ISO pour le sexe . Ou au moins se conformer aux normes partout où ils existent (merci Joe Celko!) P> 0 = not known
1 = male
2 = female
9 = not applicable
Je ne savais pas à propos de cette norme, mais il convient de définir définitivement de savoir :)
Exemple de I18N, en irlandais, les femmes sont Mná et les hommes sont de sapin. Très déroutant pour les touristes lorsqu'ils sont écrits sur des stands de salle de bain
Ceci est un non-entouré: utilisez valeurs ISO 5218 . Pourquoi réinventer la roue et rendre votre local spécifique et moins portable?
Étant donné que l'ensemble des valeurs est petit et stable, vous pouvez vous éloigner avec l'utilisation d'un vérifier contrainte ... oups, je veux dire, pour MySQL Créer une table de recherche avec une clé étrangère!
Avez-vous à l'esprit un SGBD en particulier? Le détail sera de la mise en œuvre dépendante.
Pour autant que je sache dans MySQL, les contraintes de contrôle sont cassées, vous ne seriez pas en mesure d'appliquer des sexes valides avec l'approche de la chaîne (à moins que les chaînes soignées dans une autre table FK de toute façon). Prend évidemment un peu plus d'espace que
int aussi ainsi que des règles de comparaison plus complexes (je doute que vous indexiez cette colonne de toute façon comme insuffisamment sélective)J'ai pris la peine de le repasser sur mon serveur local et les résultats ont été très surprenants, le
Char (1) est le plus rapide. Regardez ma réponse mise à jourMon repère était incorrect. Voir ma réponse mise à jour. Le
Tinyint est en fait la plus rapide. Désolé pour une telle erreur stupide ;-)