J'apprends des rails en construisant un site simple où les utilisateurs peuvent créer des articles et commenter ces articles. J'ai une vue qui répertorie les articles et commentaires les plus récents d'un utilisateur. J'aimerais maintenant ajouter des "profils" des utilisateurs où les utilisateurs peuvent entrer des informations telles que leur emplacement, leur âge et une courte biographie. Je me demande si ce profil devrait être un modèle / ressource séparé (j'ai déjà beaucoup de champs dans mon modèle d'utilisateur, car j'utilise authlogic et la plupart des champs facultatifs).
Quels sont les avantages et les inconvénients d'utiliser une ressource distincte?
6 Réponses :
Je le garderais séparé. Tous vos utilisateurs ne voudraient pas remplir un profil, de sorte que ceux-ci seraient des champs vides assis dans votre table d'utilisateurs. Cela signifie également que vous pouvez modifier les champs de profil sans changer la logique de votre modèle utilisateur.
Il s'agit essentiellement de la taille de l'utilisateur et du profil. Si l'utilisateur est 5 champs et que le profil 3, il n'ya aucun point. Mais si l'utilisateur est 12 champs et que le profil 20, vous devriez définitivement.
Pourquoi devriez-vous "définitivement" les diviser si chacun a beaucoup de champs?
dépend de la largeur de la table utilisateur existante. Les bases de données typiquement havea limit au nombre d'octets qu'un revendeur peut contenir. Je suis proche de (ou sur lequel vous pouvez généralement faire si vous avez de nombreux champs avec des valeurs nuls) la limite, j'ajouterais une table avec une relation individuelle pour une meilleure performance et moins de probabilité d'un record Ce soudainement ne peut pas être inséré car il y a trop de données pour la taille de la ligne. Si vous n'êtes nulle part près de la limite, l'ajout à la table existoire.
Je pense que vous seriez mieux servi à mettre dans un modèle séparé. Pensez à la manière dont les modèles correspondent aux tables de base de données, puis à la manière dont vous lisez celles des divers cas d'utilisation de votre application.
Si un utilisateur ne plonge que dans son profil réel une fois dans un moment, mais le modèle d'utilisateur est accessible fréquemment, vous devez certainement en faire un objet distinct avec une relation individuelle. Si les données de profil sont nécessaires à chaque fois que les données utilisateur sont nécessaires, vous pourrait vouloir les coller dans la même table.
Peut-être que l'emplacement est nécessaire à chaque fois que vous affichez l'utilisateur (disons sur un commentaire qu'ils ont laissé), mais la biographie devrait être un modèle différent? Vous devrez déterminer la bonne ventilation, mais la règle générale est de structurer les choses afin que vous n'ayez pas à tirer des données qui ne sont pas utilisées immédiatement.
Je recommanderais de garder des colonnes de profil dans le modèle d'utilisateur pour la clarté et la simplicité. Si vous constatez que vous utilisez certains champs, sélectionnez uniquement les colonnes que vous devez utiliser: Sélectionnez.
Si vous trouvez plus tard que vous avez besoin d'une table séparée pour une raison quelconque (par exemple, un utilisateur peut avoir plusieurs profils), il ne devrait pas y avoir beaucoup de travail pour les diviser.
J'ai commis l'erreur d'avoir deux tables et cela ne m'a rien acheté mais une complexité supplémentaire.
J'ai eu la même expérience.
Un utilisateur "détient" diverses ressources sur votre site, telles que des commentaires, etc. Si vous séparez le profil de l'utilisateur, il n'est qu'une seule ressource supplémentaire. L'utilisateur est statique, tandis que le profil changera de temps en temps.
La séparation de la sortie vous permettrait également de conserver facilement une histoire de profil.
Voir aussi: SoftwareEngineering.stackexchange.com/Questtions/241089/...