Y a-t-il des trous dans mon programme de référence super simple (prévu)?

Je prévois d'écrire un programme de référence pour mon démarrage récent. L'objectif est d'inciter les membres actuels à recruter de nouveaux membres. Chaque membre du site aura un code de référence et un accès à du matériel pour aider à faire la publicité du service. Lorsqu'un nouveau client s'inscrit et paie, en utilisant le code de parrainage d'un membre actuel, le membre qui a fait la référence recevra un paiement unique (environ 50% de ce que le client paie au départ). Pour ce faire, j'ajouterai 1 champ dans la table de profil d'utilisateur - pour stocker leur code de référence (généré lors de l'inscription).Y a-t-il des trous dans mon programme de référence super simple (prévu)?

Ensuite, je vais configurer une table de références pour stocker les références (date, code de référence, nouvel ID client). À la fin de chaque mois, je vais faire un rapport sur la table de référence qui indique qui est payé et combien. En utilisant PayPal, je vais effectuer les paiements.

Chaque année, je vais exécuter un rapport à des fins fiscales, puis essuyez le DB (pour garder la taille faible).

Est-ce que cela semble serré? Existe-t-il des champs/données de table que je n'ai pas répertoriés, mais que je devrais utiliser? Est-ce qu'il semble que ce serait difficile d'exploiter cette configuration?

Source

2010-02-04 Chaddeus

N'essuyez pas le DB. Quand il s'agit de tout ce qui concerne les transactions d'argent, vous devez tout enregistrer - mises à jour, modifications, modifications, insertion, suppressions, impayés, échec de l'API Paypal, connexions de base de données ne fonctionnant pas, etc.

Si vous supprimez le DB des références, vous ne pouvez pas revenir en arrière.

Source

2010-02-04 07:12:22 Extrakun

C'est un bon point. Au début, les paiements PayPal seront effectués manuellement. Donc, pas d'échecs dans l'API. Il n'y aura pas de mises à jour, le renvoi aura lieu, ou ce n'est pas le cas. Je n'ai vraiment besoin que de la DB pour savoir qui payer. À la fin de l'année, je crée un rapport, je l'imprime, je le numérise et je le garde dans un coffre-fort. Pensez que cela irait bien? – Chaddeus

Aussi, ** jamais ** faire des mises à jour. Utilisez uniquement des instructions d'insertion (faites-le avec un déclencheur de mise à jour) et utilisez un champ 'idIsActive' ou quelque chose pour suivre la version la plus récente. –

Je vous recommanderais d'utiliser des triggers sur votre table. Ils sont parfaits pour les situations de journalisation comme celle-ci. – jamieb

Bon point par ExtraKun, vous pouvez également en avoir besoin à des fins fiscales. Si vous souhaitez limiter la taille de la base de données principale, vous pouvez archiver les données dans les tables d'archivage après le rapport EOY (Fin de l'année). Vous pouvez ainsi fournir des fonctionnalités de recherche historique (ultérieurement et ultérieurement). .

Source

2010-02-04 09:43:42 TheOCD

Hmm ... Je suppose que je ne l'ai pas expliqué assez clairement. La table DB va seulement stocker le fait qu'une référence a été faite. Le processus monétaire réel est tout sous PayPal. La preuve de transaction sera sous PayPal. – Chaddeus

Y a-t-il des trous dans mon programme de référence super simple (prévu)?

Répondre

Questions connexes