IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PHP & Base de données Discussion :

Prêt à relever un défi de conceptualisation ? [MySQL]


Sujet :

PHP & Base de données

  1. #1
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut Prêt à relever un défi de conceptualisation ?
    Bonjour,

    J’ai besoin de vous pour m'aider à trouver une solution à mon problème de conceptualisation qui est assez complexe ! pour trouver une trame pour ensuite la transcrire en code.

    Donc voici le contexte, Mr A parraine des personnes, qui effectue des achats et chaque achat rapporte un gain à Mr A. Le tout est enregistré dans une table dédiée.

    Autre chose un peu spécifique et compliqué, les personnse que Mr A parraine, parraines eux aussi d'autre personne, et Mr A gagne aussi un gain à chaque achat de ces personne-là.

    Pour résumer Mr A est le parrain de Mr B et gagne 1€ sur chaque achat de Mr B.
    Mr B parraine Mr C et Mr A gagne 0.50€ de chaque achat de Mr C.

    Ensuite dans le profil utilisateur Mr A voit son total de gains et ici aussi il y a une particularité : le montant est le total gagné mais 30 jours avant la date du jour.
    Pour résumer aujourd’hui nous somme le 16 mai il ne voit que les gains obtenu du 16 avril et ultérieurement.

    Donc dans son profil utilisateur il peut grâce à un formulaire choisir le montant qu'il souhaite utiliser pour sa prochaine commande et ainsi réduire le prix de celle ci.

    Et c'est ici que je bloc, je n'ai aucune idée de comment réaliser cette manœuvre, car comme dit plus haut dans son profil l'utilisateur voit un total qui est issue de plusieurs enregistrement dans la table.

    J'ai bien entendu pensé à faire un UPDATE mais je ne vois pas trop comment faire ici.

    Exemple sur un enregistrement de la table le gain est de 10€, et sur un autre enregistrement il est de 15 €, et Mr A choisi d'utiliser parmi sa somme total 20€ il doit donc lui rester 5 € au final mais comment soustraire
    C’est 20 euros parmi les 2 enregistrements de la table ?

    Avez vous une idée ?



    Merci.

  2. #2
    Modérateur
    Avatar de sabotage
    Homme Profil pro
    Inscrit en
    Juillet 2005
    Messages
    29 208
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : Juillet 2005
    Messages : 29 208
    Par défaut
    Il te suffit d'avoir une table en plus avec les dépenses.
    N'oubliez pas de consulter les FAQ PHP et les cours et tutoriels PHP

  3. #3
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    Bonsoir,

    Soit comme dis par sabotage une table avec les dépense, soit les inclure directement dans la table que tu nous montre. L'avantage c'est que tu fait le calcul avec un SUM() tout simplement (pour cela il faut insérer en nombre négatif !).

    Mais je ferais par contre une table supplémentaire :

    Solde_Gain(id, id_user, soldes)

    Une routine qui recalcule tout les jours vers 0h le soldes sur days - 30 des utilisateurs de façon à éviter des calculs supplémentaire lors de l'affichage du soldes de chaque utilisateur.
    En effet sur un site de vente en ligne on espère en général avoir un trafic assez important, donc si on peux soulager de quelques opérations c'est toujours mieux.

    Par contre comment gère tu l'utilisation de son gain ?
    Tu actualise immédiatement son montant ou tu attends le lendemain ?

  4. #4
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    donc vous proposez de créer une table qui contient la somme total des gains d'une personne et c'est celle la avec la quelle je travail par la suite. Je comprends.

    Tu parle de routine, c'est genre tâche cron? si on admets que l’hébergeur ne permet pas de faire cela, comment faire une routine sql autrement ?

    Actuellement je procède ainsi, la personne paye, une fois le paiement validé, cela s'enregistre dans une première table "orders" puis je calcule en php le % de gain suivant le montant payé de la commande puis cela s'enregistre dans cette table gains (en photo plus haut).
    Et donc si je vous suis je devrait faire le calcul de la somme de tous les gains puis de faire une autre requête pour faire un insert / update et enregistrer le tout dans une troisième table ?

    Je pense que le tout ferais dans les 4 requêtes facile car j'en ai déjà 2. avec des conditions si la personne a déjà un total de gain on fait un update et sil elle en a pas un insert ?

    C'est pas un peu lourd ?

    merci pour vos conseils en tout cas! ça me fait réfléchir

  5. #5
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    je viens juste de comprendre votre conseil

    donc je créer une autre table dépense, ca me fait donc une table gain et dépense et après je comprend q"on peut afficher combien il reste mais ce résultat n'est pas enregistré . il faudrait prévoir un champ spécial dans la table dépense pour enregistrer le montant total qu'il reste ?

  6. #6
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    (Mal)heureusement en informatique on a souvent la possibilité de faire une chose de diverse façon, chacune apportant sont lots d'avantage et d’inconvénient.

    Citation Envoyé par thecatz
    Tu parle de routine, c'est genre tâche cron? si on admets que l’hébergeur ne permet pas de faire cela, comment faire une routine sql autrement ?
    En fait quand je dis routine c'est plutôt en terme généraliste pour dire que c'est une tâche qui doit s'effectuer tout les jours. Que ce soit pas un cron (c'est vrai que c'est plus propre), un démon, un service, un scipt, ...

    Par contre en examinant ta table quelque chose vient de m’apparaître, qu'est-ce que la colonne "bon d'achat", est-ce qu'il s'agit de la réduction appliqué à la facture ?
    Dans ce cas tu as déjà ta solution sous les yeux

    Citation Envoyé par thecatz
    Actuellement je procède ainsi, la personne paye, une fois le paiement validé, cela s'enregistre dans une première table "orders" puis je calcule en php le % de gain suivant le montant payé de la commande puis cela s'enregistre dans cette table gains (en photo plus haut).
    Et donc si je vous suis je devrait faire le calcul de la somme de tous les gains puis de faire une autre requête pour faire un insert / update et enregistrer le tout dans une troisième table ?

    Je pense que le tout ferais dans les 4 requêtes facile car j'en ai déjà 2. avec des conditions si la personne a déjà un total de gain on fait un update et sil elle en a pas un insert ?

    C'est pas un peu lourd ?
    C'est pour ça que je te parlais de routine, si tu commence à avoir pas mal de visite il va falloir optimiser tes requêtes pour utiliser le moins possible de bande passante et avoir une navigation fluide. Sinon les utilisateurs iront voir ailleurs.
    Du coup puisque tu affiche le solde de compte d'une personne à J-30 cela me parait intéressant dans ton cas d'effectuer les calcul de gain tout les jours à heure plus ou moins fixe.
    Pour l'utilisation d'une troisième table c'est discutable, je pense qu'au début ce ne sera pas un gain; entre un SELECT SUM(SUM(gain) - SUM(bonachat)) FROM table2 et un SELECT gain FROM table3 ce dois pas être énorme avec une centaine d'enregistrement.
    Par contre vu que tu dois prendre en compte le filleul et le sous-filleul sa va commencer à te faire de la ligne, surtout que l'on doit pouvoir avoir plusieurs filleul ?
    C'est dans ce cas que j'utiliserai une troisième table pour stocker les gains.

    Pour la question de l'insert / update je la résoudrai ainsi :
    A la création du compte on insert la ligne de l'utilisateur dans la table3 avec un gain = 0. Ainsi tu est sur de ne faire que des updates.

  7. #7
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    En faite je n'ai pas parler de la case bon d'achat pour ne pas complexifier les choses encore plus. En faite le champ bon d'achat peut recevoir comme paramètre 1 ou 0 par défaut elle est sur 0 ce qui veut dire que la personne souhaite recevoir la somme qu'elle a choisit parmi c'est gains en réduction. Mais si ce champ reçoit comme paramètre 1 cela veut dire que la personne souhaite un virement sur son compte bancaire. Ce champs bon d'achat "peut être mal nommé" me permet juste de m'y retrouver suivant le besoin du client, réduction ou virement.

    Je vais relire ton message car j'ai 36000 questions dans ma tête.

  8. #8
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    Bon en admettant que j'ai une table gains qui comme ici enregistre les gains de chaque client. Puis une table dépenses qui elle liste toute les dépense de chaque client. Je comprends " la routine" qui permet a heure fixe de mettre a jour une troisième table "soldes" qui sera le calcul somme des gains - somme des dépenses. C'est bien ça?

    C'est un aspect que je n'ai jamais traité par moi même, en admettant que l’hébergeur ne me permets pas de faire des procédure stockées, ni de tâche cron. Il me reste qu'elle solution ( a part de changer d’hébergeur ) ?

    disons une solution simple pour un novice comme moi, car même si je passe par une procédure stocké la requête risque d'être assez complexe, disons que je n'ai jamais encore fait cela.

    En tout cas merci encore pour les conseils !

  9. #9
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    Citation Envoyé par thecatz Voir le message
    Bon en admettant que j'ai une table gains qui comme ici enregistre les gains de chaque client. Puis une table dépenses qui elle liste toute les dépense de chaque client. Je comprends " la routine" qui permet a heure fixe de mettre a jour une troisième table "soldes" qui sera le calcul somme des gains - somme des dépenses. C'est bien ça?
    Oui.

    Citation Envoyé par thecatz Voir le message
    C'est un aspect que je n'ai jamais traité par moi même, en admettant que l’hébergeur ne me permets pas de faire des procédure stockées, ni de tâche cron. Il me reste qu'elle solution ( a part de changer d’hébergeur ) ?
    Hum, la pour le coup je t'avoue que je ne sais pas trop.
    Sans cron et sans procédure tu risque d'être bloquer. A moins de faire un script php mais il faut trouver un moyen de pouvoir l'appeler à une certaine heure et être sur que le script ne sera lancé qu'une fois.

  10. #10
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    Ok je vais m'arranger pour cette partie là cependant j'ai une nouvelle colle car dans le schéma des tables c'est assez complexe.
    Tout d'abord pour faire la somme des gains par exemple je vois pas trop comment additionner les gains d'une même personne. Car je dois mettre comme condition sélectionne tous les gains d'une seule personne et additionner les.

    Mais si on regarde la table gain elle ne donne que l'information du montant et non de l'appartenance à un membre.

    Exemple pour afficher le gain d'un parrain je procède comme cela pour afficher les gains dans le profil de la personne:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    $gains  = $DB->query("SELECT * from gains, users WHERE users.email_parrain =:email AND users.id = gains.user_id",array('email'=>$_SESSION['user']['email']));
    ici j'utilise par chance la table users qui a un champs avec l'email du parrain et je dit si ton email de session et dans le champs email_parrain affiche les gains (pour résumer).

    Mais la notion de super parrain n'existe pas à savoir le parrain du parrain.

    Donc làa je ne vois vraiment pas comment faire une somme contenu dans les champs gain_parrain et gain_supparain en ayant juste pour info l'email du parrain contenu dans la table user et juste le montant des gains dans la table gains ???

    Ps : user_id de la table gains et l'id de la personne qui a passé commande non du parrain.

    Voici la table user en image :

    Nom : oo.png
Affichages : 70
Taille : 10,0 Ko

    C'est un vrai défi n'est ce pas ?

  11. #11
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    En fait ton problème vient d'une mauvaise conception de ta base de données.

    Tu devrais supprimer email_parain et super_parain, en plus cela te créer de la redondance d'information dans tes tables ce qui est, d'un point de vue d'analyse, très mauvais.

    Pourquoi ne pas simplement stocker l'id du parain ?idParrain INTEGER REFERENCES Users(id)Ainsi pour récupérer tes parrains et sous parrains c'est tout de suite plus simple.

    Pour un utilisateur ça donnerai :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    SELECT id FROM
    (SELECT id FROM Users WHERE idParrain = 1) as filleul
    UNION
    SELECT id FROM Users WHERE idParrain IN (SELECT id FROM filleul);
    Et la tu récupère direct tous les filleuls et sous filleuls

    Par contre ce type de requête ne marche pas sur toute les base de données, c'est le cas de mysql. Dans ce cas faut faire comme ça, c'est moche mais sa marche bien :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT id FROM Users WHERE idParrain = 1
    UNION
    SELECT id FROM Users WHERE idParrain IN (SELECT id FROM Users WHERE idParrain = 1)

  12. #12
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    pour être sur, voici comment fonctionne la Table gains :

    - Une personne commande un article à 100 € je récupérer l'id de cette personne et je le range dans le champs user_id

    - le montant de la facture est de 100€, va dans le champ montant_facture

    - la date du jour de la commande va dans date_facture

    - gain parrain est égale à 8% du montant de la facture ici 8€

    - gain_supprain 2% donc 2€

    - l'id facture et l'identifiant de la facture en question.

    Ici il n'y a pas de relation parrainage a proprement dit, c'est juste du stockage tout bête. Donc les champs gain_parrain et supparain n'appartienne a personne juste calculé suivant le montant de la facture.

    Donc si je fais un somme des champs gain_parrain et gain_supparain par utilisateur ca donnerait

    user_id 34 ( par exemple) à généré 800 € en gain_parrain et 200€ à gain_supparain avec toutes ses commandes mais c'est la seule information que la table gains va me donner. Donc ensuite je vais devoir faire le lien avec la table user pour connaitre a qui correspond c gain.

    Qui est le parrain de user_id 34 et donc qui a gagné 800€ de gain.

  13. #13
    Membre confirmé Avatar de Periah
    Homme Profil pro
    Chef de projet en SSII
    Inscrit en
    Août 2012
    Messages
    27
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet en SSII
    Secteur : Conseil

    Informations forums :
    Inscription : Août 2012
    Messages : 27
    Par défaut
    Ce que tu cherches à savoir, c’est quel est le montant disponible à une certaine date pour un utilisateur, c’est bien ça ?

    Pour faire ça, tu peux :

    • Créer une table des dépenses : depense(id_user, date_depense, montant)
    • Modifier ta table des utilisateurs pour ajouter l’identifiant du parrain (plus propre que le mail).
    • Laisser ta table des gains comme elle est.


    Quand tu veux connaitre l’avoir disponible d’un utilisateur à une date, tu fais la somme de gains réalisés avant cette date en tant que parrain et la somme en tant que super parrain et tu soustrais la somme des dépenses effectuées avant cette date.
    Et pour identifier de qui l’utilisateur est le parrain ou le super parrain, tu utilises les requêtes de humitake

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    Select sum(montant)
    From gain
    Where id_user in (SELECT id FROM Users WHERE idParrain = #id#
    UNION
    SELECT id FROM Users WHERE idParrain IN (SELECT id FROM Users WHERE idParrain = #id#))
    And date_facture < #date#

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    Select sum(montant)
    From depense
    Where id_user = #id#
    And date_depense < #date#

    Avec #id# et #date# à remplacer par tes valeurs.

  14. #14
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    question tu dis "Modifier ta table des utilisateurs pour ajouter l’identifiant du parrain (plus propre que le mail)." je récupère cette email lors de l'inscription via le formulaire, comment est ce possible de récupérer l'id du parrain ? sans aucune information

  15. #15
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    Eh bien rien ne t'empeche de récupérer l'idUser du mail au moment de l'inscription.

    En fait quand je dis "plus propre" c'est surtout dans la pérénité des données.

    Actuellement que se passe t'il si un utilisateur change de mail ? Tu modifie tous les mails de la table user qui contiennent ce mail ? Genre :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    UPDATE Users SET email = "new@mail.fr" WHERE email = "old@mail.fr";
    UPDATE Users SET email_parrain = "new@mail.fr" WHERE email_parrain = "old@mail.fr";
    UPDATE Users SET super_parrain = "new@mail.fr" WHERE super_parrain = "old@mail.fr";
    Ce qui fait 3 requête avec plusieurs modification pour les deux dernière requêtes.

    Avec la technique des id lors de l'inscription tu récupère l'id du parrain grâce à son email, l'id du super_parrain tu l'as déjà dans l'id_parrain du parrain (faut suivre ).
    Et du coup en cas de changement de mail tu n'effectue qu'une requête, qui n'effectue qu'une seul modification

  16. #16
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    hola j'avais pas pensé à ça .

    Ok donc je m'inscrit et je remplis tous les champs dont email_parrain (je dois tout de même conserver cela). comment alors récupérer au même moment l'id du parrain et du super parrain.

    bon je vais préparer la corde et commencé a m'enrouler le cou...

  17. #17
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    Au moment de l'inscription il te suffit d’exécuter cette requête SQL :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT id FROM Users WHERE email = "email@parrain.fr";
    --Ou email@parrain.fr est l'email du parrain renseigné par l'utilisateur
    Et hop te voile en possession de l'id de ton parrain.

    Oui je te vois venir, "mais il le fait exprès ce c** ! Et mon super_parrain alors !!!", pas de panique

    En fait la notion de super_parrain n'a pas à être présente en base de données car il s'agit, en fait d'un parrain de second niveau (parrain de parrain quoi).
    Pour avoir ton super parrain il te suffit de récupérer le parrain de ton parrain :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    SELECT id_parrain as id_super_parrain FROM Users WHERE id = (SELECT id_parrain FROM Users WHERE id = id_user);
    --Il te suffit de l'adapter en changeant id_user selon le cas.

  18. #18
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    ok merci, je vais tout relire et travailler de mon coté je reviendrais une fois tout cela terminé et venir polluer le forum de mes 500 questions

  19. #19
    Membre confirmé
    Inscrit en
    Juillet 2007
    Messages
    72
    Détails du profil
    Informations forums :
    Inscription : Juillet 2007
    Messages : 72
    Par défaut
    Bonjour,

    je reviens sur le sujet avec de nouvelles infos . Bon tout d'abord je vais suivre vos conseils et je vais passer par une tache cron qui fera le calcul gain - dépense et qui rempli une table solde par utilisateur. Ce qui est simple et que j'ai mis en place. Cependant, on ma demandé malgré vos différentes remarques de gardé la structure actuelle, c'est a dire le fonctionnement avec les emails...

    Et j'ai donc un problème histoire de changer, je n'arrive pas a formater ma requête correctement pour passer de ma table users et gains a une 3 eme table qu'on appellera total_gain.

    Cette table a pour but de contenir un champ id, id_membre, montant.
    Jusqu'ici rien de bien compliqué mais j'ai toujours le problème du champ id_membre.

    Pour rappel voici ma table users :



    et voici ma table gains :



    Donc je prends ici comme exemple mon dernier membre enregistré Mr test qui a comme id 41. Il a fait gagné a son parrain 1.59€ qui est l' id 35 et qui a aussi fait gagner 0.59€ à l'id 34

    Ce qui dans l'idéal me donnerais comme table total_Gains cela :



    Et c'est pour réaliser cela que je n'arrive pas a m'en sortir car pour dire " affiche moi la somme de gain_parrain et gain_supparain et donne le résultat a la bonne personne".

    J'arrive a faire facilement la somme par membre du champs gain_parrain par exemple mais pour attribuer ce gain a la bonne personne je n'ai pas réussi a trouver...

    Si vous aviez une idée, je suis preneur merci

  20. #20
    Membre chevronné Avatar de humitake
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2010
    Messages
    399
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2010
    Messages : 399
    Par défaut
    Bonjour,

    Dommage que tu ne puisse pas utiliser un id, c'est quand même plus propre, m'enfin

    Pour récupérer l'id d'une personne c'est plutôt simple :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    SELECT id FROM Users WHERE email = "email_de_la_personne_a_qui_tu_veux_voir_les_gains"
    Eh bien sur la même base pour récupérer les gains de cette personne il suffit de faire :
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    SELECT SUM(gain_parrain) FROM Gains WHERE user_id IN (SELECT id FROM Users WHERE email_parrain = "email_de_la_personne_a_qui_tu_veux_voir_les_gains")
    UNION
    SELECT SUM (gain_supparrain) FROM Gains WHERE user_id IN (SELECT id FROM Users WHERE super_parrain = "email_de_la_personne_a_qui_tu_veux_voir_les_gains");
    Il suffit ensuite de faire un insert avec les deux valeurs récupéré, c'est bien un truc comme ça que tu cherche à faire ou je suis à coté de la plaque ?

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Réponses: 21
    Dernier message: 23/01/2013, 12h50
  2. Quels défis IT devront relever les entreprises en 2011 ?
    Par Idelways dans le forum Actualités
    Réponses: 0
    Dernier message: 14/01/2011, 14h15
  3. Y-a t-il plusieurs algorithmes de calcul de l'amortissement d'un prêt?
    Par kouka dans le forum Algorithmes et structures de données
    Réponses: 9
    Dernier message: 12/09/2007, 13h33
  4. Défis à relever
    Par jerem_psg dans le forum C++
    Réponses: 6
    Dernier message: 31/01/2006, 00h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo