Alors je suis coincé. Je travaille sur un système de crédit avec des expirations. Semblable aux miles de carte de crédit mais pas exactement. Au fait, je suis désolé pour le livre à venir, mais je devais ajouter suffisamment de détails pour vous aider à obtenir la photo entière.
Ce dont j'ai besoin est un système dans lequel un utilisateur accumule des crédits pour faire des activités. Mais ils peuvent également dépenser ces crédits sur les activités. Les crédits devraient expirer après 30 jours si elles ne sont pas utilisées. Je semble être coincé sur la façon de calculer avec précision cela dans un lot qui fonctionnera tous les soirs. Toute idée dans n'importe quelle langue serait grandement appréciée car il semblerait être coincé sur un seul détail mineur que je ne peux pas me contenter. Voici un exemple des données:
7/1: +5 - L'utilisateur s'inscrit sur
7/2: +5 - Utilisateur interagit avec le système
7/2: -3 - Achats d'utilisateurs d'activité
7/3: +5 - Utilisateur interagit avec le système
Ainsi, à ce stade, l'utilisateur a reçu 15 crédits et a dépensé. 3. Le laissant avec un total de 12 crédits. (Au moins j'ai eu des mathématiques de base en bas: p)
Je devrais ajouter que nous jouons actuellement avec l'idée d'avoir deux champs: Dernière traitée, ensuite traitée. Donc, ces valeurs en ce moment en supposant que c'était une nouvelle inscription sont:
Date du dernier traité: 7/1
Date de processus suivante: 8/1
Alors maintenant 8/1 vient autour. Le lot commence et examine tous les crédits de plus de 30 jours. Qui à ce stade est 5.
C'est là qu'il commence à devenir flou.
Ensuite, le système devrait examiner tous les crédits dépensés au cours des 30 derniers jours pour voir si elles utilisent des crédits. Parce qu'ils ne devraient expirer que s'ils n'ont pas été utilisés. Donc, il y en a 3. Donc, je déduisez ensuite les crédits utilisateur 2 car c'est la différence de crédits gagné de plus de 30 jours et de ce qui a été dépensé. Donc, j'ai fini le lot et définir les dates en conséquence pour le lendemain. En supposant maintenant qu'ils n'ont plus dépensé, je commence le calcul des crédits gagnés de plus de 30 ans, ce qui est 5 et que les crédits dépensés sont à nouveau 3. Mais je ne veux évidemment pas envisager les 3 crédits que j'ai envisagés hier. Quelle est une bonne approche pour ne pas inclure à nouveau ces 3 crédits pour examen.
C'est là que je suis coincé.
Nous pensons à écrire un enregistrement de débit pour les crédits expirés afin que nous puissions les suivre, mais avoir du mal à voir comment je peux l'utiliser dans ce calcul.
Si vous lisez ceci vous remercie beaucoup. Si vous même faire un effort un peu dans la réponse que je vais au minimum vous donner un vote pour l'effort.
EDIT:
Ok mentionné quelque chose que @ Greg j'ai oublié de l'adresse. L'idée de mettre un drapeau sur les crédits considérés. Un très bon point mais qui ne peut fonctionner en raison du scénario suivant:
Le mot Let que sur un jour donné un utilisateur passe 10 crédits. Mais les crédits périmés que le lot est on ne considère que accumulé à 5. Eh bien il devrait encore avoir 5 plus des crédits reste pour ne pas avoir expiré parce qu'il a passé plus d'une expiration. Ainsi, le drapeau ne fonctionnerait pas parce que nous aurions sauté ces 5 crédits supplémentaires. L'espoir qui fait sens?
7 Réponses :
Que diriez-vous d'ajouter un drapeau aux dépenses? Si le drapeau n'est pas défini, vous pouvez inclure ces dépenses dans le lot, si nécessaire. Si vous utilisez les dépenses pour compenser une expiration, vous définissez le drapeau. La prochaine fois, vous allez ignorer cette dépense car le drapeau est défini.
Merci d'avoir mentionné que je pense avoir laissé un peu de détail de mon post. Permettez-moi d'ajouter ça maintenant.
Je n'envisagerais pas d'essayer de traiter les données comme vous le présentez. Au lieu de cela, vous devriez garder une trace du nombre de crédits que l'utilisateur dispose et quand ils expirent. De cette façon, vous gardez une trace de quels crédits ont été utilisés lorsque l'achat est effectué, au lieu d'essayer de tout travailler plus tard.
Ainsi, lorsque l'utilisateur s'inscrit, ils ont: P>
2 credits expiring on 8/1 5 credits expiring on 8/2
Une bonne idée de l'interface utilisateur, mais c'est un mauvais moyen de stocker réellement les données; vous voulez un sentier d'audit au cas où l'une ait un bug pour corriger
@Heath: En effet, ce n'est pas un remplacement d'un journal de transaction approprié. Cependant, en utilisant quelque chose comme celui-ci, et traite le journal des transactions comme n'appuyant essentiellement qu'à moins que quelque chose ne soit pas correct, est, IMO, le meilleur moyen d'aller de l'avant.
@Heath je dois être d'accord. Je ne veux pas toucher les enregistrements qui indiquent combien de crédits ont été gagnés. J'ai envisagé cette idée, mais je pense aux fins de la Heath mentionnée sur un sentier d'audit, je ne peux tout simplement pas voir comment je pourrais implémenter cela proprement dans un système de stockage.
@Anon Je ne suis pas complètement opposé à l'idée si vous avez un bon moyen de la mettre en œuvre et de ne pas ajouter trop de frais généraux. Cette table sera déjà assez grande car nous traitons avec près de 100 000 utilisateurs. Donc, garder une trace de leur activité quotidienne comme celle-ci deviendra gros. Ajout d'une autre table pour suivre presque des données en double ne semble que la bonne approche. Mais on pourrait manquer quelque chose.
@spinon: Les journaux de transaction seront essentiellement en écriture uniquement - au lieu d'un enregistrement de toutes les transactions au cours des 30 derniers jours, vous pouvez maintenir un point de vue de 30 entiers par utilisateur et avoir toutes les informations nécessaires pour calculer les temps d'expiration, les soldes etc. Écrivez les journaux sur le disque et conservez les données utilisateur en mémoire (les totaux de crédit ne seront sur l'ordre des mégaoctets pour votre compte d'utilisateur prévu).
Donc, si je comprends bien correctement. Vous dites que pour chaque utilisateur, je stockerais un enregistrement pour tous les crédits expirant un jour donné. (Nous considérons que 30 jours, les 30 enregistrements par utilisateur droit?) Donc, dans mon scénario en haut, je disposerais des enregistrements suivants: 8/1 = 5 8/2 = 5 8/3 = 5 Maintenant, lorsqu'ils achètent l'activité pour 3 Crédits Je soustrai-il du plus ancien record du montant de l'activité, non? Si c'est le cas, que se passe-t-il si l'activité coûte plus que les crédits de ce jour-là? J'aurais besoin de boucler à travers chaque enregistrement d'expiration jusqu'à ce qu'il atteigne le total dont j'ai besoin, non?
@Spinon: Oui, vous vous en protégeriez de l'expiration - la plus tôt à expirer au plus tard jusqu'à ce que vous aviez pris suffisamment de crédits pour couvrir le coût.
Cela semble de loin le moyen de sankers de gérer les choses.
Utilisez un enregistrement de débit pour enregistrer des dépenses normales. Lorsque le travail par lots mensuel est exécuté, il peut calculer le total des débits inférieurs ou égaux aux crédits expirants. S'il y a des crédits d'expiration, insérez simplement un enregistrement de débit approprié (approprié == pour annuler l'excédent, dans votre application). De cette manière, tout code «en cours d'exécution» qui examine que des crédits et des débits n'atteint que le même équilibre que votre code de lot était destiné.
Je suis d'accord et j'ai mentionné cela un peu. Mais cela ne résout toujours pas mon problème, au moins je ne vois pas comment en ce moment, quant à la manière de ne pas envisager les 3 crédits passés dans le lot le lot le lot. Bien que je pense qu'il y a quelque chose avec ça. Nous écrivons également l'enregistrement de débit sur la table et nous mettons à jour la colonne globale avec ces informations.
Pour chaque utilisateur du système Gardez un tableau, cela stocke des informations sur la quantité de crédits à la disposition de l'utilisateur pour les 30 prochains jours consécutifs
par exemple, par exemple, les données de certains utilisateurs peuvent ressembler à ceci < Pré> xxx
Chaque fois que l'utilisateur gagne certains crédits, vous augmentez les montants pour tous les jours par le nombre de crédits gagnés. Par exemple, si l'utilisateur gagne 2 crédits, le tableau change comme suit. C'est comme la hausse de l'ensemble du graphique. Si l'utilisateur a x crédits aujourd'hui et dépense y des crédits Y, vous réduisez la quantité de crédits à la disposition de X-Y, pour Chaque jour, il a un montant supérieur à X - Y. Pendant des jours, il n'a plus que X - Y, le montant reste le même. C'est comme couper le haut du graphique. Par exemple, si l'utilisateur dépense 3 crédits, le graphique passe à chaque jour, vous déplacez le graphique vers la gauche pour modéliser les crédits expirants. L'utilisateur aura les montants suivants demain
Je vous donnerais +1 pour le montant de l'effort que vous ressemblez à cela. Permettez-moi de regarder cela pendant quelques minutes pour donner un sens à ce que vous avez dit. Mais rapidement en la lutte juste, vous avez mentionné avoir une table pour chaque utilisateur. Était-ce une faute de frappe ou est-ce que ce que vous vouliez dire? Parce que nous avons près de 100 000 utilisateurs et une table pour chacun seraient un peu hors de contrôle. Alors tu veux juste avoir du sens de cette pièce tout de suite.
@spinon Ok, merci pour la remarque. la table est un mauvais mot. Un artefact de mon anglais pauvre. Je ne voulais pas dire une table de base de données, mais juste une certaine structure qui détient des quantités et permet de les associer avec des jours. Il pourrait s'agir d'un tableau simple en dehors de la base de données. Je vais essayer de la rehrasser dans une édition. En cas de base de données, utilisez simplement 30 colonnes pendant 30 jours et stockez les données pour un utilisateur d'une ligne.
Ok je comprends ça. Permettez-moi de continuer mes tests contre elle.
@spinon Désolé, j'ai commis une erreur dans la description des crédits de dépense. Je voulais dire "plus grand" au lieu de "non plus grand". C'est réparé.
En supposant que vous exécutez ce lot quotidiennement, vous pouvez avoir une table qui tient une trace de tous les crédits qu'ils ont gagnés et les crédits qu'ils utilisaient (crédits négatifs).
Au début du mois prochain, votre travail consiste simplement à déterminer lequel des crédits gagnés le premier jour n'a pas été dépensé au cours du mois.
Le nombre de crédits gagnés le premier jour - les crédits qu'ils ont passé tout le mois dernier. Si le nombre est positif, ils ont des crédits qui doivent être expirés. Si simple ajoutez un enregistrement dans la table avec un crédit négatif. Cela mettra zéro les crédits inutilisés.
Le lendemain, répétez le processus en voyant combien de crédits qu'ils ont gagnés le deuxième jour moins la somme de tous les crédits qu'ils ont gagnés au cours du dernier mois, en tenant compte de l'enregistrement avec les crédits négatifs que vous avez créés le jour précédent.
J'ai l'impression que c'est l'approche que j'essayais de travailler avec et cela ne semble tout simplement pas fonctionner. Pouvez-vous résoudre un exemple pour démontrer cela?
Une approche de ce problème est de stocker uniquement les transactions, pas l'équilibre. Ensuite, vous calculez toujours le solde en temps réel en cas de besoin. Voici les données:
Date : Amount : Expiries 7/1 : +5 : 7/31 7/2 : +5 : 8/1 7/2 : -3 : never 7/3 : +5 : 8/2
Concernant Julians Répondre (que je ne peux pas encore commenter), je traite de même que le même problème et que Julians approche ne fonctionnera pas car cela résulterait du compte de pouvoir devenir négatif.
Si l'utilisateur n'utilisait pas le service pendant un mois, le solde du compte serait de -3 et une activité de 5 apporterait la balance à 2, et non à 5, comme il le devrait.