Comment puis-je stocker la hauteur et le poids d'un utilisateur dans une base de données MySQL de telle sorte que je puisse utiliser les informations pour trouver des utilisateurs dans une certaine hauteur ou une certaine poids? En outre, je devrai être capable d'afficher ces informations dans un système anglais ou métrique.
Mon idée est de stocker les informations de hauteur en centimètres et poids en kilogrammes (je préfère la métrique sur l'anglais). Je peux même laisser l'utilisateur entrer dans son système d'information et d'anglais, mais faire la conversion en métrique avant d'économiser. Je pense que la conversion des kilogrammes en livres pourrait être facile à faire dans SQL, mais je ne sais pas à quel point il serait facile de convertir Dois-je économiser des valeurs anglaises et métriques dans la base de données afin que je n'ai pas besoin de faire des conversions lorsque je fais mes questions? Cela ressemble à une mauvaise idée de stocker des valeurs dérivées / calculées. 178 centimètres vers 5'10 " (arrondi légèrement vers le bas).
4 Réponses :
Je ferais cela de la façon dont vous avez dit que vous aimeriez le faire, mais sur la partie convertie, vous ne convertiriez pas 178 centimètres à 5'10 ", vous le convertiriez à 70", puis si besoin d'être , convertir cela en 5'10 ".
jworrin - 178 CMS peut être facilement converti en 70.08 pouces, mais les utilisateurs préféreraient probablement voir 5'10 ". Si le SQL renvoie < Code> 70.08 pouces et je dois appliquer un traitement supplémentaire en plus des résultats, je suis concerné que cela pourrait potentiellement être lent. Que pensez-vous?
Je ne pense pas vraiment que le traitement supplémentaire serait tout ce qui est génial. Prenez en compte la fréquence à laquelle vos utilisateurs vont également vouloir voir leurs informations dans le système anglais. De toute façon, je pense qu'il est inapproprié de le stocker dans les systèmes anglais et métrique.
Attendez, vous dites que vos utilisateurs sont présentés avec la sortie RAW de votre requête SQL? Qu'est-ce que vous utilisez???
Jamie - J'utilise la lampe. La recherche d'utilisateur peut être quelque chose comme: trouver tous les utilisateurs entre 5'5 "et 5'10". Je veux afficher la hauteur / le poids dans le format que l'utilisateur préfère.
Je suis d'accord que le stockage des valeurs calculées dans ce cas n'est pas correct. Vos choix sont parfaits.
Cependant, je ferais les calculs au niveau de l'application et interrogerais la base de données avec ces valeurs - en fonction de la langue de votre demande, je suis sûr qu'il y a beaucoup de bibliothèques / modules qui sont faits qui peuvent calculer ces transformations .
Modifier - pour résoudre le problème de stocker des valeurs calculées dans dB:
Bien que cela soit considéré comme une mauvaise pratique en matière de travail avec DBS, je ne suis généralement pas à 100% contre cette pratique - seulement 90%.
J'ai tendance à stocker des valeurs calculées en DB uniquement lorsque les calculs sont complexes et prendraient des ressources énormes pour atteindre le résultat recherché - ceci est clairement Si vous stockiez des valeurs calculées ici, vous n'auriez que les inconvénients de cette technique - lors de la modification d'un enregistrement, vous devez modifier les données dans plusieurs endroits pour conserver la cohérence de votre DB
Pourquoi stocke des valeurs calculées "pas d'accord"?
Flimzy, je pense que la conservation des valeurs calculées pourrait être considérée comme des données redondantes. Tu ne penses pas?
Les données redondantes sont l'une des meilleures façons d'optimiser les performances dans une base de données. Je le fais tout le temps. Cela peut enfreindre certaines caractéristiques de forme normalisée, mais lorsqu'il est une forme normalisée, ou toute autre "standard" gêne le travail effectué, puis il est survécu.
Cela ne veut pas dire que la conservation de ces valeurs en tant qu'OB et à la conversion à l'heure d'affichage est faux ... juste que c'est loin de la seulement approche valide.
FLIMZY, je suppose que vous avez modelé Tudor. Je vous demande que vous ne modifiez pas les gens de Mod simplement parce que vous êtes en désaccord. Je suis personnellement en désaccord avec votre réponse ci-dessous, mais je vous donne la courtoisie de reconnaître que vous pouvez avoir une expérience que je ne le fais pas. Les suggestions pour le moment bas sont ici: Stackoverflow.com/privileges/vote-down
penser à 5'10 "comme 70" ou 5.8333333 '. Dans ce cas, la conversion entre 70 "ou 5.83333 est juste une multiplication, de sorte qu'il est facile à stocker dans la DB comme centimètres si vous le souhaitez.
Le problème de ce que l'utilisateur voit est un problème de présentation et rien à voir avec la base de données.
Jamie - Création d'un script pour convertir 70 " sur 5'10" est trivial. Toutefois, si je dois introduire un grand nombre de résultats de requête pour faire cette conversion, je suis préoccupé par une performance frappée.
Vous ne feriez que la conversion lors de la présentation de l'utilisateur, vous le feriez dans la couche d'interface utilisateur et tout moment de conversion sera minuscule par rapport à toutes les autres choses qui se passent. Si vous vouliez rechercher la base de données pour toutes les hauteurs entre 5'10 et 6'2, vous convertiriez les deux entrées de requête en CM en premier, (c'est-à-dire deux conversions), puis exécutez cette requête.
Il y a plusieurs façons ... une pour avoir deux colonnes numériques, une pour la hauteur, une pour poids, puis effectuer les conversions (si nécessaire) au moment de l'affichage. Un autre consiste à créer une table "hauteur" et une table "poids", chacune avec une clé primaire liée à partir d'une autre table. Ensuite, vous pouvez stocker des valeurs anglaises et métriques dans ces tables (avec toutes les autres informations de Meta souhaitées):
SELECT * FROM users JOIN height ON users.height = height.id WHERE height.inches >= 48 AND height.inches <= 60;
Flimzy, si je comprends votre solution correctement, j'aurais user.height_id (fk)? Si oui, cela ne ferait-il pas un peu plus compliqué pour moi de faire appel à des gammes?
Je viens de mettre à jour ma réponse avec comment interroger ... laissez-moi savoir si j'ai besoin d'expliquer plus.
J'ai déjà recommandé ce livre à un autre lecteur aujourd'hui, mais Entreposage de données Toolkit est le livre que j'ai lu sur cette forme de "tables de dimensions", et je vous recommanderais de le lire si vous travaillez sur une sorte de projet considérable. Il y a probablement de meilleurs livres sur le sujet, mais c'est celui que je connais, et c'est le tour pour moi.
FLIMZY - J'essaie de digérer votre solution. Que pensez-vous de stocker des centimètres et de faire les conversions à la volée?
Il n'y a rien faux avec cette méthode. Cela fonctionnera probablement très bien pour ce que vous faites - surtout si votre demande est relativement petite, et vous savez que vous n'élargirez pas sa fonctionnalité principale (en particulier la manière dont il se rapporte à la hauteur et au poids, etc.).
Dites-vous que vous avez eu un maximum de 1 000 utilisateurs? Quelle approche utiliseriez-vous? Et si vous aviez 500 000 utilisateurs?
i utiliserait l'approche que j'ai décrite ci-dessus. Mais cela ne signifie pas que l'autre approche est fausse. Mon approche commence vraiment à briller pour d'autres dates de données plus complexes. Indexation d'une colonne DateTime et une recherche sur une colonne DateTime est à la fois FAR plus chère que l'indexation et la recherche contre une colonne INT qui fait référence à une table de date.
Quelle est votre technologie au-delà de MySQL. Comment vous présentez votre présentation de ces informations à vos utilisateurs?