Architecture de base de données pour système "Badge" et critères arbitraires (MySQL / PHP)

Selon la distance que vous voulez aller avec, votre schéma peut devenir assez compliqué. Il me semble que les éléments de base que vous devez suivre sont:

Badges awarded
Points earned

Assez simple jusqu'à présent, mais vous voulez être en mesure de créer dynamiquement de nouveaux badges et de nouvelles catégories de points. Les récompenses de Badge dépendront du gain de points dans une ou plusieurs catégories de points qui totaliseraient un certain montant. Vous devez donc suivre la relation entre les catégories de points (et les points gagnés) et badges:

Point categories
Badge categories

La clé serait donc votre table de points utilisateur, qui relierait aux catégories de points, qui relient aux badges. Les utilisateurs gagnent des points dans une catégorie particulière, ce qui contribuerait à gagner des points vers un ou plusieurs badges.

badges:
badge_id
badge_name
required_points
....

point_categories:
point_id
category_name
weighting (optional)
...

point_groups:
badge_id
point_id
weighting (optional)
...

user_points:
user_id
point_id
points
...

user_badges:
user_id
badge_id
points_earned
badge_awarded (yes/no)
...

Votre interface "admin" permettrait à quelqu'un de créer un nouveau badge et de choisir les catégories de points nécessaires pour obtenir ce badge (point_groups). Chaque fois qu'un utilisateur gagne des points (user_points), vous mettez à jour la table user_points, puis déterminez quels badges ces points pourraient contribuer à (point_groups). Vous recompilez ensuite les points pour les badges qui ont été affectés par les points gagnés et mettez à jour la table user_badges avec le point_earned. Ensuite, vérifiez le champ points_earned dans user_badges contre les required_points dans la table badges.

Vous pouvez obtenir beaucoup plus fantaisiste en attribuant des poids différents à différentes catégories de points, ou même des poids différents pour les catégories de points pour des badges particuliers. Mais cette configuration serait permettre un nombre illimité de badges et de catégories de points à créer et à gérer assez facilement sans changer les structures de tables.

Si ce n'est pas tout à fait ce que vous cherchez, alors je pense que je devrais au moins obtenir un vote ou deux pour beaucoup de frappe.

Vous devez suivre vos utilisateurs uniques dans une table et les badges uniques dans une autre, puis créer une table de références croisées pour les relier.

Un utilisateur peut avoir plusieurs badges et un badge peut avoir de nombreux utilisateurs.

create table users (
id int,
name varchar
)

create table badges (
id int,
badge_name varchar
)


create table user_badges_xref (
user_id int,
badge_id int
)

Les statistiques qui peuvent affecter si un utilisateur gagne un badge sont suivies dans le cadre de l'administration du site. donc, quelque chose comme une réponse acceptée serait dans un schéma qui concerne les questions et les réponses. pour afficher la réponse et le propriétaire de la réponse, il y aurait une relation avec la table utilisateur et des déclencheurs qui vérifieraient les conditions de badge chaque fois qu'une modification était apportée.

Je ne demande pas comment attribuer des badges. Je demande comment stocker les critères dans la base de données.

Si vous souhaitez stocker l'opération logique nécessaire pour déterminer si un badge est gagné dans un champ quelque part?

Je pense être d'accord avec l'autre affiche que les critères devraient faire partie de la logique métier. Cette logique peut être sur l'application côté ou dans un déclencheur. Je pense que c'est une question de style.

Si vous étiez vraiment marié à l'idée de stocker les critères dans un champ, je le stockerais en SQL paramétré et l'exécuterais dynamiquement.

Donc, ce genre de chose serait dans votre champ de critères:

select "Badge Earned"
from all_posts 
where user_id = @user_id
having count(*) > 10000

Je ne créerais pas d'incrément pour le badge d'édition. Je pense que vous devriez avoir un travail en arrière-plan et compter() le nombre de post édité pour les membres qui n'ont pas encore le badge d'édition. Lorsque vous voyez que le nombre est sur la plage que vous voulez, vous ajoutez une entrée dans la base de données qui indiquent que l'Utilisateur a le badge.

Je pense que c'est à peu près la même chose pour les autres badges. Essayez de limiter le nombre d'écriture et n'écrivez pas directement le nombre d'informations de badge dans le table utilisateur. Utilisez une table qui contiendra des informations de badge et les liera à la table utilisateur.

Je m'excuse d'être bref.

Pour implémenter un système comme celui-ci, je pourrais créer une table qui stocke les noms de procédure stockés ou les requêtes réelles qui seraient utilisées pour déterminer si un utilisateur particulier a gagné un badge.

badge_criteria
badge_key int
badge_criteria varchar(max)

Vous pouvez extraire et exécuter les requêtes pour les badges que l'utilisateur n'a pas gagnés de votre niveau intermédiaire, mais vous n'auriez pas à apporter de code ou de modifications structurelles pour ajouter de nouveaux badges à l'avenir.

Je l'aborde comme ceci: Créer une table pour stocker tous les badges, et avoir une colonne Référence une fonction qui est exécutée pour voir si le badge est attribué. De cette façon, la table reste simple et la logique pour déterminer les badges peut être conservée dans le code, où elle est la mieux adaptée.

Avec cette méthode, les exigences de badge pourraient également être liées ensemble, pour former des dépendances plus complexes. Par exemple, l'utilisateur doit recevoir trois badges distincts et spécifiques dans un certain délai afin de obtenez ce badge.

Cela va être presque impossible à faire dans la base de données-l'attribution des badges devrait être faite dans votre logique métier dans l'application. De cette façon, vous avez toutes les données existantes dont vous avez besoin (modifications, visites, réputation, etc.) et il peut être traité comme bon vous semble.

Mise à jour:

Si par critères vous entendez des règles qui déterminent si et comment le badge est attribué, alors ce n'est pas quelque chose qui devrait être stocké dans la base de données. Ce serait presque impossible à tester et maintenir.

Si vous voulez dire, par exemple, stocker le "nombre de modifications", il n'y a aucun moyen de modifier une table ou une procédure stockée pour inclure ces données si vous en avez besoin.