Question

J'ai déjà lu quelques questions sur l'enregistrement des préférences des utilisateurs, mais elles semblent faire principalement référence à un ensemble assez minimal de préférences. Je travaille actuellement sur une application Web hautement personnalisable, qui nécessitera de stocker un grand nombre de préférences, et j'ai du mal à les stocker.

Le type de préférences que je vais stocker inclut des booléens pour afficher des info-bulles spécifiques, la disposition de divers panneaux de contenu sur une page, la page à afficher après la connexion, les valeurs par défaut de champs de formulaire spécifiques, etc. Je m'attends à ce qu'il y ait plus de 50 préférences de ce type pour chaque utilisateur, les données étant principalement des valeurs booléennes et des entiers.

Je ne suis pas un grand fan de la sérialisation, mais je suis préoccupé par l'évolutivité du stockage de chaque préférence sous forme de ligne individuelle. Des pensées?

Était-ce utile?

La solution

La sérialisation d'une goutte de données est la solution, mais pas pour des raisons de performances - il s'agit plutôt d'un aspect du système susceptible de subir un nombre considérable de changements. Vous ne voulez pas avoir à changer votre schéma de base de données simplement parce que vous devez maintenant autoriser une préférence pour activer le mode avancé sur une page ou quelque chose.

Le modèle d'entité, d'attribut et de valeur mentionné par HLGEM convient à cela depuis un "facile à faire évoluer". perspective, mais comme il le dit, ses performances seraient très médiocres.

Ce que vous abandonneriez avec les objets sérialisés, c’est la possibilité d’interroger directement la base de données sur les utilisateurs correspondant à un certain modèle (vous êtes peut-être en train de localiser un bogue qui ne se produirait qu’avec une combinaison de paramètres et que vous voulez voir si vous avez des utilisateurs qui ont cette combinaison).

Autres conseils

quoi que vous fassiez, évitez d'utiliser la structure entity-attrivute-value ( http: //en.wikipedia.org/wiki/Entity-Attribute-Value_model ) sauf si vous voulez un système très peu performant. Un appel à une table avec 50 colonnes sera beaucoup plus rapide qu'un appel à une table auquel vous devez vous connecter 50 fois pour obtenir toutes les informations dont vous avez besoin.

Je créerais un tableau associé pour chaque groupe de préférences général (préférences de connexion, préférences de site générales, préférences de page ou de fonctions spécifiques) en le basant sur la façon dont vous avez l'intention de rechercher les préférences (si vous souhaitez tout récupérer en vous connectant tirez ceux qui sont nécessaires pour l’ensemble du site lors de la connexion et ceux qui ne sont nécessaires que pour les domaines spécialisés lorsque l’utilisateur y accède, ainsi que leur combinaison) et ont les colonnes booléennes pour le type de préférences défini dans celui-ci. Ainsi, toutes les préférences dont vous aurez besoin pour chaque zone du site seront regroupées dans le même tableau ou au plus deux ou trois tableaux, ce qui facilitera la récupération des informations. C'est un endroit où la conception est essentielle à la performance (vous rechercherez les préférences tout le temps, donc même les millisecondes comptent), vous devez donc prendre en compte les performances d'abord dans votre conception. Il est bien plus important ici que de vouloir faire en sorte que cela paraisse orienté objet ou que le développeur ait moins de travail lors de la configuration.

Je ne sais pas si je voudrais même stocker des informations telles que les préférences de l'utilisateur dans une base de données. Il semble que vous souhaitiez consulter plusieurs (sinon toutes) les préférences de l'utilisateur dès qu'il se connecte; si vous finissez par faire un tas de requêtes de base de données, votre système sera assez lent. Au lieu de cela, je vous recommande de conserver TOUS les paramètres de l'utilisateur dans un seul fichier (ou un enregistrement quelque part), de les avaler en gros et de les mettre en cache dès que l'utilisateur se connecte.

En supposant que les données de l'utilisateur soient déjà stockées dans une base de données, je ne vois pas de réel problème pour les stocker toutes sur une ligne, en particulier si vous devez effectuer des requêtes basées sur les données, par exemple. sélectionner tous les utilisateurs avec la préférence A, B, etc.

Je voudrais cependant le charger dans une classe et la conserver via un mécanisme de mise en cache.

Si vous n'avez pas besoin de rechercher dans les préférences, vous pouvez toujours les enregistrer au format XML et les enregistrer dans un fichier "Préférences". colonne. Cela devrait faciliter l’ajout de nouvelles préférences dans le futur;)

Une autre option que vous pouvez utiliser (si vous n’avez pas besoin de stocker vos éléments dans une base de données, par exemple pour vérifier les statistiques (qui fait quoi, etc.)), vous pouvez simplement mettre tous leurs paramètres dans un cookie et les stocker. sur leur machine.

bien sûr, avec les cookies vient toutes les mises en garde de l’utilisation de cookies. mais juste une autre idée ...

Il existe certaines préférences que l'utilisateur préfère davantage (tous les animaux sont égaux mais certains sont plus égaux que d'autres). Ceux-ci devraient être spécifiquement optimisés pour la récupération et l'application sur l'interface lors de la connexion. Au fur et à mesure que la profondeur de préférence diminue, ils peuvent être agrégés à l'aide de tout critère et enregistrés en tant que colonnes séparées, éventuellement sous forme de tableaux (la colonne de préférence de police comprend le type, la taille et la couleur de la police et fait référence à une table de polices). Indexez également les colonnes fortement utilisées à l'aide de l'outil de base de données et modifiez-les de manière à fractionner les colonnes agrégées de manière à pouvoir identifier l'élément de l'agrégation qui fait l'objet d'une forte demande.

Dans l’ensemble, les préférences utilisateur ont tendance à être très statiques (c’est-à-dire qu’elles sont une habitude), ne confondez pas les données utilisateur qui sont plus facilement modifiables avec les préférences.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top