Sh@rdar > n'hésites pas a faire ton topic "optimisation mysql "; ) ;) ;)
art_dupond
oki... :jap:
gizmo
oui, suffit d'intérogger une variable du cookie, si elle n'existe pas, c'est que le cookie a été refusé.
art_dupond
au fait, c'est possible de savoir si le cookie a ete accepte ?
art_dupond
oki merci
sinon ca m'interesserai le truc sur l'optimisation mysql
youdontcare
il reste la possibilité d'utiliser un cookie qui a la même durée de vie que celle du browser (pas de date d'expiration spécifiée).
art_dupond
Sh@rdar a écrit a écrit :
les sessions avec un forum, rien de tel pour tout faire ramer......
surtout qu'en général c'est la partie la plus fréquentée d'un site, le serveur aura intérêt à suivre.
comment faut faire alors pour reconnaitre quelqu'un tout au long des pages ?
[edtdd]--Message édité par art_dupond--[/edtdd]
gizmo
ouais, moi je cherche désespérement une table qui donnerait pour des valeurs types (100 enregistrement de 10 champs par exemple) le nombre de cycle processeur et la taille mémoire utilisée.
Sh@rdar
on devrait faire un thème sur l'optimisation MySQL, mine de rien y a pas mal de fonctions peu utilisées qui évitent souvent des traitements lourds au niveau script.
idem concernant les types de champ, je crois qu'il y a un tutorial bien foutu sur phpfance.com
gizmo
:ouch: Ah bon, ca je savais pas, c'est pas comme ca dans toutes les DB en tout cas (Access par exemple). Bon dans ce cas, effectivement, ta méthode est mieux, je vais changer dans mon code.
Sh@rdar
je me suis mal expliqué,en fait quand tu fais une sélection de champs sur plus d'une table MySQL effectue un join (dixit la doc). Donc la manière (et le résultat) sont les mêmes :D .
Par contre tu peux joindre les tables sans inclure tout les champs c'est de l'optimisation.
gizmo
non, le résultat est le même, mais pas la manière de travailler. Jan un Join, il va crée un vue, donc une sorte de table fantome qui prend de la place mémoire. C'est utile si on a beaucoup de champs a vérifier avec plusieurs interactions, car alors la jointure est fait et il ne doit pas parcourir les table a chaque fois. Mais pour un forum ou tu ne sort pas plus de 20 réponses a la fois, cette manip est beaucoup plus lourde car elle joint la totalité des 2 tables, alors qu'on en utilise qu'une tout petite partie.
Sh@rdar
euh... c'est exactement la même chose, ta query est en fait un JOIN :sarcastic:
gizmo
simplement par SELECT noms_des_champs.nom_des_tables FROM nom_des_tables WHERE ...
Ainsi tu évites de créer une vue par une jointure, c'est du temps de gagné.
Sh@rdar
explique, je voudrais bien savoir moi :D
gizmo
non non, je fais pas comme indiqué plus haut, ni comme avec ta méthode. je fais bien un select mais sans joindre les 2 tables, comme ca je gagne encore du temps.
Sh@rdar
bin tu peux faire une mise en page exactement de la même façon qu'en traitant les lignes en boucle php, mais là la query te sors la ligne d'un coup.
un autre exemple : quand tu mets les titres, messages et profils dans des tables séparées, tu aurais tendance à faire ça :
$Query = ("query qui récupère les messages" );
while ($Query......) {
query qui récupère les profils;
affichage des messages;
affichage des profils;
}
eh bien tu peux optimiser le tout pour ne faire qu'une query et récupérer d'un coup le nom du profil qui a posté ton message.
ça donne une query comme ça :
SELECT * FROM forum_post LEFT JOIN forum_profils ON forum_profils.Auteur=forum_post.Auteur WHERE Pere=$post ORDER BY forum_post.Date
et là tu gagne encore du temps puisque les informations des deux tables sont sorties en une seule query.
jm'en va lancer un topic sur l'optimisation des query pour forum moi..
gizmo
oui, mais la mise en page de concat est assez limitée et ca ne se prête pas vraiment a un forum.
Sh@rdar
en fait le pb c'est que à chaque fois qu'un visisteur arrive sur ton site, le serveur doit vérifier/ouvrir/fermer une session, mais il délivre en plus les pages et envoie les requêtes au serveur BDD, tout ça ça bouffe des ressources si en plus t'as quelques centaines de visites simultanées, le serveur aura du mal à tout gérer.
on s'imagine à tort que les requêtes ralentissent, mais en général, elles sont plus rapides que tout les traitements PHP/ASP qui servent à traiter les résultats.
Ex : plutot que de faire des boucles while($val=mysql_fetch_array($Req)), essayes plutôt de faire une seule query SQl en CONCAT qui te sortira tous les résultats, gain de rapidité garanti !!
gizmo
ca bouffe tant que ca? plus que les accès aux db?
Sh@rdar
les sessions avec un forum, rien de tel pour tout faire ramer......
surtout qu'en général c'est la partie la plus fréquentée d'un site, le serveur aura intérêt à suivre.
gizmo
sh@rdar>> c'est pas pour le transformer en tour imprenable mais juste pour savoir si ca apportait un plus ou non. visiblement non, merci.
Barbarella>> oui, je sais, suffit de jouer avec les sessions.
barbarella
salut,
il existe une autre solution que les cookies du moins en grande partie et il faut saisir le passe au moins une fois pour l'ensemble du site.
Mais bon le propre de la sécurité c'est de ne rien dire, donc je me tais ;)
[edtdd]--Message édité par Barbarella--[/edtdd]
Sh@rdar
putain jsuis trop crevé moa :sleep: alors le cryptage est peut être superflu mais ça sert à rien non plus de se faire chier à vouloir protéger ton forum autant que fort knox :D le mieux serait de le protéger contre le flood (type le plus courant d'attaque), en vérifiant la page d'ajout, pour éviter le flood depuis un script externe.
gizmo
et alors, tu fais view source et tu l'as... c'est pas difficile. Qualqu'un qui sait lire les cookie sait afficher le code HTML d'une page
Sh@rdar
il est pas en clair (en tout cas pas ici) puisque c'est un champ password.
gizmo
bah oui, mais comme il est repris en clair dans le formulaire de post, ca sert a rien!
Sh@rdar
le crypter évite (à mon humble avis) à qq'un de pouvoir le lire à l'insu de ton plein grè.
De toute façon rien n'empeche de refuser le cookie et de devoir saisir ton pseudo/mot de passe à chaque fois.
gizmo
Je suis en train de faire un forum en php et donc je regarde un peu partout comment ca marche. Et j'ai remarqué que la plupart mettent un cookies pour reconnaitre la personne (normal). Mais la ou c'est bizarre, c'est qu'ils incluent aussi le password sous un forme cryptée, comme ici.
Alors ma question est: y a-t-il un intéret de cripter le password dans le cookie? sachant que si je copie le cookies ailleurs il marche et que le password préremplit dans les formulaire est le vrai password (donc lisible dans le code HTML).
