Discussion :

[feelwatt]

Bonjour,
Dans mes développements, j'ai l'habitude (idiote ?) de charger les données à chaque rafraîchissement ou changement de page.
Même lorsqu'il n'y a pas eu de modifications de la BD.
>>> Et ca fait travailler les serveurs et ils chauffent et ce n'est pas ce qui est préconisé pour notre belle planète

Généralement, on a deux types de pages:
Pages de listes: ex liste de tous les adhérents avec peu d'infos (nom, prénom,ville, tel, mail)
Page type 'fiche': La fiche d'un adhérent avec cette fois ci tous ces infos.

Alors je me posais cette question,
Est-il judicieux de:

1. Charger tous les listes dans des Array sessions dès l'arrivée du visiteur
   (comme ca plus d'appel à la BD lorsque l'on change de page)
2. Pour les pages 'fiche': Cette fois-çi, charger toutes les infos à partir de la BD en variables normales
   et de recharger uniquement la session de cet adhérent lors d'un Update

• Mais pour les listes ca risque de faire volumineux pour le client,
• il y a-t'il une limites de stockage en ko pour les sessions (notamment pour les Smartphones) ?
• Est que des Cookies seraient mieux ?

Qu'en pensez-vous ?

[rawsrc]

Salut,

la meilleure soluce c'est de faire appel à un serveur de cache de type Memcached.
Laisse tomber le stockage local.
Je préfère de loin réserver le stockage local pour les formulaires multipages par exemple. Ce qui te permet de réafficher les données déjà saisies et ne soumettre le tout une fois la saisie finie.

[feelwatt]

Ah Ok, Memcached.
je vais regarder ca.

[feelwatt]

Salut,
j'ai regardé Memcached,
apparemment il faut l'installer,
aussi, comme je ne sais pas encore sur quel hébergeur, je vais posé mon développement,
je crains de devoir galérer avec l'installation sur l'hébergeur que j'aurais choisi.

Comment fonctionne d'ailleurs ce site developpez.net/
(qui est foisonnant en BD) notamment en forums.

Ils ne doivent pas charger tous les messages de toutes les discutions, si ?

[rawsrc]

Salut,

DVP s'étale (je pense) sur au moins une dizaine de serveurs dédiés (vu le nombre de pages affichées tous les jours et les temps de réponse). Et doit utiliser un gestionnaire de cache performant pour soulager les serveurs BDD.
Après, savoir quels sont précisément les données techniques, c'est confidentiel ne serait-ce que pour des raisons de sécurité (moins tu exposes de surface d'attaque et mieux c'est)

[feelwatt]

Au sujet de la sécurité Mysql et des injections néfastes,
Il y a html specialchars...

Mais je trouve que ca permet à une personne d'essayer plusieurs fois d'attaquer les BD.

J'ai pensé à un truc cette nuit.

1. Faire un array avec tous les termes MySql dangereux (DELETE, TRUNC, DROP, <script ...)
2. Sur les submit, vérifier chacun des POST s'ils contiennent un de ces termes
3. Si c'est le cas: Blacklister l'adresse ip et bloquer le compte en changeant le Mdp

Il y a aussi des requetes utilisant GET,
du type: (SELECT * Form table WHERE id=:id) puis execute(array('id'=>$_GET['id']))
là aussi on peut checker la valeur des GET.

L'idée c'est de virer direct un user qui cherche des noises.
Sans le laisser essayer d'autres choses.

Qu'en pensez-vous ?