Dans une application d'information de nouvelles, notre client nécessite de stocker tous les ID d'articles qui sont lus par un utilisateur.
Nous avons décidé de créer une table unique pour cela, mais de performance point de vue, lequel des énoncés suivants est une meilleure approche:
ou s'il y a une meilleure façon, les suggestions sont très bienvenues.
user_id et article_ids , puis chaque fois qu'un utilisateur lisait un article, appendez l'ID au texte article_ids - à l'aide de la mise à jour et concat (nous pourrions nous retrouver avec une énorme donnée dans une colonne) .
user_id et article_id , puis chaque fois qu'un utilisateur lisait un article, insérez le article_id avec le user_id dans un nouvel enregistrement (nous pourrions vous retrouver avec trop de lignes) .
3 Réponses :
Essayez de les diviser autant que possible. Votre performance sera beaucoup augmentée si, parce que vous devez simplement choisir de petites pièces de votre base de données. Si vous optez pour la première option, vous devez la diviser après certains caractères pour obtenir les informations souhaitées. Tout d'abord, il est plus difficile dans la programmation et si un utilisateur a une mauvaise connexion Internet, l'application serait très lente.
Avec la deuxième approche, vous pouvez garder une trace d'autres choses que votre client pourrait demander d'aller de l'avant.
Dans cette approche, vous pouvez appliquer l'indexation sur article_id ultérieurement si nécessaire.
De nombreux enregistrements, un pour chaque avec des index propres, il n'y a pas vraiment une telle chose que trop de lignes. user_id et article_id combinaison. C'est beaucoup plus facile à mettre à jour (simplement insérer une ligne, pas besoin d'appliquer la logique) et vous permet également d'obtenir des informations sur les articles lorsque vous souhaitez lister lesquels un utilisateur a lu. Vous pouvez utiliser une jointure et récupérer les informations correctes de la base de données à la fois, au lieu d'avoir à convertir une chaîne en IDS, puis revenir à la base de données pour obtenir les données supplémentaires.
En général, la deuxième approche est meilleure.
@Gordonlinoff ne récupère pas une seule ligne vaut mieux que de récupérer plusieurs rangées? J'ai lu que certains où IIRC.
Vous n'avez pas dit comment vous souhaitez utiliser les données - voulez-vous pouvoir identifier des articles qui n'ont pas été lus ou ont été lus ou combien d'articles un utilisateur a lu ou utilisateurs classés par le nombre d'aritcles lus , ou des articles par le nombre d'utilisateurs - presque certainement l'approche 2 est meilleur pour tous. Je ne peux pas penser à un cas d'utilisation où 1 fournit un meilleur modèle pour utiliser les données que nous avons stockées ... mais il y a beaucoup de gens plus imaginatifs que moi!
Encore une fois, en fonction de la manière dont vous souhaitez utiliser les données, vous pouvez souhaiter une table qui relie l'utilisateur à l'article avec un horodatage - vous permettant de suivre plusieurs accès au même article par le même utilisateur.
J'irais également pour la deuxième approche, cela vous facilitera la tâche si vous avez besoin d'aller chercher ou de compter les utilisateurs qui lisent un article spécifique, par exemple