Hello HFR ,
 
J'ai deux questions un peu théoriques sur le fonctionnement d'une base de donnée de sites web. (type MySQL, je connais que ça, et pas bien comme vous risquez de vous en apercevoir )
 
1) Première question
 
Mettons que je veuille une table dont, sur chaque ligne, l'une des valeurs (une valeur numérique du coup) serait une fonction de d'autres valeurs (numériques aussi) de cette ligne, et que je veux que le calcul se fasse automatiquement.  
 
(Comme je sais pas si je suis clair, je mets en spoiler une tentative d'exemple concret de ce que je veux dire)

 
Ma question est donc : comment je fais pour que ma table actualise ces valeurs automatiquement, à intervalles réguliers par exemple.
- Est-ce qu'il y a un coin de phpMyAdmin qui permet de mettre en place des scripts qui se lancent toutes les X secondes ou dès qu'un événement donné arrive, et qui actualiseront ma table ?
- Ou est-ce que je dois avoir quelque part sur le serveur de mon site web une page php qui fait ça (et en deux mots, comment je fais pour qu'elle s'exécute à intervalles réguliers) ?
- Ou est-ce qu'il y a un autre moyen, et/ou autre chose qui m'échappe ?
 
2) Deuxième question
 
Ma deuxième question est "qu'est-ce qui m'évitera que tout saute et que la société qui héberge ma base de donnée gueule" : en terme de "charge", qu'est-ce qui est le plus viable ?
- que la table s'actualise toute seule à intervalles réguliers courts (genre toutes les secondes ou toutes les 5 secondes),  
- qu'elle s'actualise à chaque fois que quelqu'un a besoin de consulter la valeur qui est fonction des autres (dans mon exemple, le "score" de mes réponses)
- ou qu'elle s'actualise à chaque fois qu'une des valeurs qui sert de paramètre à ma fonction est modifiée (dans mon exemple, mes votes + et -)
 
 
J'espère que j'ai été clair, n'hésitez pas si jamais. N'hésitez pas à me répondre avec le vocabulaire d'un enfant de 5 ans, je suis encore loin de maîtriser ce dans quoi je me plonge  
Merci d'avance pour vos réponses !

Qu'est ce qui t'empêche d'avoir deux colonnes dans ta table de réponses :
- VotePlus
- VoteMoins
 
Et qu'au niveau de ta requête, tu gères ça via un ORDER BY ?

1)
- ca s'appelle un trigger http://dev.mysql.com/doc/refman/5. [...] yntax.html
 
- ou avec cron qui lance un script php qui mets à jour ta base  
 
2) un trigger avec une simple mise à jour de compteur est gratuite en perf , a moins que tu ne me parle de plusiseurs dizaines/centaines de reqûetes par seconde.  
Un autre bonus est que , par construction, les triggers assureront un résultat fiable, même si tu as plusieurs requêtes en parallèle.

Okay okay, merci pour vos réponses (je réponds tardivement parce que je plongeais le nez dans les triggers)

Ce que j'ai en tête est plus compliqué et prend en compte plus de paramètres, je peux pas juste faire un ORDER BY VotePlus, VoteMoins;

Merci pour les triggers, ça a l'air de pouvoir faire une partie de ce que je veux. Ceci dit, cron a l'air beaucoup plus puissant, en termes de choses différentes que je peux faire, non ? Si je me trompe pas, ça a l'air de pouvoir gérer un autre aspect de mon projet pour lequel j'avais aucune idée de comment le gérer, du coup j'ai des questions dessus

J'ai regardé rapidement cron (mais pas en profondeur), du coup deux trois questions sur cron pour être sur que je perdrai pas du temps en me plongeant dedans :
- Si je veux utiliser cron, j'ai pas besoin d'être sous unix (je suis sous windows), il faut seulement que le serveur le soit, non ? Ou j'ai rien compris ? Tu aurais un lien vers un tutoriel simple et clair sur cron à me conseiller, ou je prends le premier truc qui vient sur google ?
- Est-ce qu'un site comme reddit, qui fait tourner un algorithme pour ranker les liens/posts soumis par les utilisateurs, utilise cron pour actualiser sa table qui répertorie ces soumissions ? Ou ils font autrement ? Si c'est autrement, ils utilisent quoi comme système ?

Sous Windows tu as les tâches planifiées. MySQL permet aussi l exécution de requêtes planifiées

Wokay, merci pour l'info je vais aller regarder.
 
Reste ma question sur reddit et comment ça marche

c'est quasi du temps réel avec l'équivalent du trigger. reddit ne stocke pas sans dans une base de données relationnelle

Tu pourrais aussi tout simplement faire une vue, non ?
 
Avantages
- toujours à jour
- appelé uniquement à la demande
 
Inconvénients
- les requêtes sont refaites à chaque fois (en gros), donc c'est plus coûteux point de vue performances

Je suis pas sur d'avoir compris : ils utilisent des triggers (ou un truc équivalent), mais ils utilisent du nosql, c'est ça ?

J'ai survolé un peu les vues ici (http://openclassrooms.com/courses/administrez-vos-bases-de-donnees-avec-mysql/vues), je ne suis pas sur de voir en quoi une vue peut m'aider ici ?

-

Autre question (dites moi si vous préférez que je créé un nouveau topic) : je suis chez online.net et apparemment j'ai pas le droit de faire de trigger sur mes tables, une idée de pourquoi ? J'ai aussi tenté de faire une procédure stockée, et même chose. Du coup j'ai créé un domaine gratuit sur 000webhost.com pour tester des trucs, j'ai pas l'air d'avoir droit de créer des triggers et des procédures stockées non plus (et sur webhost, quand j'essaie de crééer une procédure stockée, ça me sort cette erreur (même après un REPAIR TABLE) : "#1547 - Column count of mysql.proc is wrong. Expected 20, found 16. The table is probably corrupted."

(Merci pour vos réponses en tout cas, c'est cool de trouver de l'aide)

Les hébergeurs mutualisés imitent souvent les possibilités, en particulier sur les abonnements les moins chers
Du coup, sois tu prends un serveur dédié (mais c'est plus cher), soit tu trouves un hébergeur qui te propose les triggers/procs stockées, soit tu passes par le cron (ou un webcron si vraiment ton hébergeur fait le radin).
 
Tu peux aussi (et c'est conseillé), pour le dév, travailler en local avec un wampserver.

Ok merci pour la réponse, donc c'est bien ce qu'il me semblait, j'avais peur que ce soit moi qui comprenne rien. A priori cron a l'air d'être inclus donc je vais passer par là, d'autant que si j'ai bien compris ça me permet bien plus de choses que les triggers et procs stockées.

Du coup, question code maintenant. Si je veux aller lire, pour chaque ligne, le nombre d'upvote et le nombre de downvote, puis en calculer un score, et inscrire ce score dans un autre champ de cette même ligne.

Est-ce que ça, ça fonctionne ?

Il faut quelque chose en particulier derrière le WHERE j'imagine non ? (pour que ça traite la ligne visée)

Attention, si t'as beaucoup d'enregistrements dans ta BD, faire trop de requêtes pourrait poser pb chez certains hébergeurs mutualisés. J'ai eu le cas il y a un an avec OVH : au bout d'un certain nb de requêtes faite dans un court laps de temps dans un même script, la connexion à la BD était coupée. Du coup, mon script php continuait à fonctionner mais les requêtes SQL ne passaient plus. C'était dû à un paramètre de mysql que l'hébergeur mettait pour se protéger du flood.
 
J'ai donc dû recoder une partie de mon appli web pour faire moins de requêtes SQL et stocker plus de données dans des gros Array. Ca a marché (mais c'était pas naturel du tout, j'ai changé d'hébergeur)

J'ai compris la première partie du message, par contre je suis pas sur d'avoir compris comment tu as résolu le problème ^^
Mais pour être honnête c'est le genre de problème dont je me soucierai une fois que mon machin fonctionnera (quitte à upgrader mon hébergeur si j'ai pas d'autre choix).
 
(Du coup le code, il fonctionnera, il manque des choses ? )

Ben au lieu de faire pleins de petites requêtes SQL de type SELECT, j'en fait moins mais des plus grosses.
Ex : si j'ai ne boucle où à l'intérieur, y' aune requête du genre :
SELECT ... FROM ... WHERE ID = $i;
 
Ben je stocke tous les $i dans un Array et je fais un  
SELECT ... FROM ... WHERE ID IN (".implode(", ", $Array)." )"
Bien sûr, après, j'ai un while qui parcourt le résultat de cette requête et stocke tous les enregistrements récupérés dans un gros tableau associatif (où chaque clé est un champ du SELECT).
 
Ca fait plus qu'une seule grosse requête SQL au lieu de pleins de petites. Ca n'améliore pas forcément les temps d'exe, mais ça diminue grandement le nb de requêtes. Après, pour trouver les valeurs d'un enregistrement, je tape dans le tableau associatif.

Ooohh okay, je connaissais pas implode, mais j'ai quand même compris le principe, merci pour l'explication !

Dans mon cas, vu que je veux pas seulement lire chaque ligne, mais la lire et la modifier (en fonction de ce que j'y ai lu), c'est possible de faire la même chose non ?
C'est à dire si je me plante pas, dans l'ordre : un array où je mets tous les ID -> une grosse requête SQL qui me sort les machins que je veux pour chaque ligne -> je mets tout ça dans un array -> je fais mes calculs sur chaque ligne de l'array -> puis une grosse requête où je remets les résultats dans la table.
Makes sense ?

Ben tu peux faire un UPDATE matable SET score = (nombre_upvotes - nombre_downvotes) WHERE 1
 
Mais je ne comprends pas pourquoi tu ne le fait pas à l'affichage : SELECT [mes autres champs], (nombre_upvotes - nombre_downvotes) AS score WHERE 1

Je sais que c'est pas hyper clair ici, mais la réponse c'est que mon calcul (que je simplifie ici en "score = nb_upvote - nb_downvote" ) est pas juste un calcul en fait, mais un algo : je compare certains des paramètres entre eux et selon les cas, j'applique une formule différente pour calculer ce que je veux. Pour donner un exemple simple (qui n'est pas ce que je veux faire, c'est juste histoire de faire comprendre) si nb_upvote-nb_downvote<0, je préfère dire que ça vaut 0 dans mon calcul, plutôt que de prendre le résultat de la soustraction. J'espère que je suis clair ^^... Bref, et à ma connaissance, je peux pas faire ce genre de choses dans une requête... après je me trompe peut être...

Accessoirement, même si c'était pas un algo mais juste un calcul (je suis pas sur que je pourrai me passer de l'algo, mais imaginons que je puisse y arriver et tout mettre ça sous la forme d'un seul calcul), ce serait un calcul dans lequel j'ai une 30aine d'inputs (pas seulement un nombre d'upvotes et de downvotes), certains que je somme ou multiplie entre eux, d'autres que je divise entre eux, etc. Je connais pas bien SQL mais du peu que j'en ai vu, mon instinct me dit que mettre un calcul avec une trentaine de paramètres dans une requête, ça doit pas forcément passer super bien...

Après j'ai peut être faux sur toute la ligne hein, mais j'apprends encore

Ne pas sous estimer mysql, tu peux faire des calculs assez complexe de façon relativement gratuite, en tout cas pas rapport à un SELECT + traitement php + UPDATE.
 
Tu as tout un tas de fonctions mathématiques : http://dev.mysql.com/doc/refman/5. [...] tions.html
Et la possibilité de conditionner avec CASE : http://dev.mysql.com/doc/refman/5.1/en/case.html
 
Si ton calcul est complexe, privilégie l'UPDATE au SELECT mais dans ce cas, ne le fait que quand une des valeurs de ta 30aine d'INPUT change, à priori tu n'as pas besoin d'un cron qui vas modifier toutes tes lignes pour ton cas de figure...

J'ai fait du calcul matriciel avec Mysql : tX*X (transposée de X fois la matrice elle-même).