Discussion :

[ddaweb]

Bonjour,

Je fais la refonte d'un site avec une base de données et j'ai 2 possibilités de travailler :

1. créer un array au login avec les informations utiles et il est mit en session (qui serait mit à jour si une nouvelle données)
2. faire une requête sql quand les données sont nécessaires

Quelqu'un peut me dire la méthode qui serait la plus rapide, la plus efficace ?

Je dois dire qu'il s'agirait de plusieurs array à 2 dimensions avec plus de 1.000 lignes chacun : liste des codes postaux - liste des vétérinaires - liste des compagnies d'assurance - etc ...

Ce que je fais :
1. j'affiche la valeur d'un élément lors de l'affichage
2. j'affiche la valeur + la liste complète si c'est une modification

Je me doute que le array va prendre de la place place mémoire.
Je suis sur un hébergement mutualisé.

Pouvez-vous me conseiller sur la meilleure méthode à utiliser.

D'avance merci,
ddaweb

[ddaweb]

J'ai vite écrit comment je travaillerais avec un array :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
// --------------- Création du ARRAY et mise en SESSION au login
$reponse=mysqli_query($conn, "SELECT vetos_id, vetos_nom, vetos_prenom, vetos_ville, id_postal, full_postal
	FROM 03_chien_vetos v 
	INNER JOIN 02_prop_postal p ON v.vetos_ville=p.id_postal 
	ORDER BY vetos_nom ASC") or die(mysqli_error($conn));
while ($in= mysqli_fetch_array($reponse)) {
	$vetos_id=$in['vetos_id'];
	$vetos_nom=$in['vetos_nom'];
	$vetos_prenom=$in['vetos_prenom'];
	$vetos_full_postal=$in['full_postal'];
 
	$array_vetos[$vetos_id][id]=$vetos_id;
	$array_vetos[$vetos_id][prenom]=$vetos_prenom;
	$array_vetos[$vetos_id][nom]=$vetos_nom;
	$array_vetos[$vetos_id][postal]=$vetos_full_postal;
}
 
// --------------- Afficher la valeur à l'affichage
print "$array_vetos[$vetos_db][nom] $array_vetos[$vetos_db][prenom] - $array_vetos[$vetos_db][postal]";
 
// --------------- Afficher la liste déroulante à la modification
print "<select>";
	print "<option value=\"$array_vetos[$vetos_db][id]\">$array_vetos[$vetos_db][nom] $array_vetos[$vetos_db][prenom] - $array_vetos[$vetos_db][postal]</option>"; // ----- valeur actuelle
 
	foreach ($array_vetos AS $boucle1) { // ----- Liste complète
             if ( !in_array( $vetos_db ) ) {
		foreach ($boucle1 AS $boucle2) {
			$veto_liste_id=$boucle2[id];
			$veto_liste_prenom=$boucle2[prenom];
			$veto_liste_nom=$boucle2[nom];
			$veto_liste_postal=$boucle2[postal];
			print "<option value=\"$veto_liste_id\">$veto_liste_nom $veto_liste_prenom - $veto_liste_postal</option>";
		}
            }
	}
print "</select>";

Via les requêtes SQL, j'utilise une fonction pour l'affichage et la requête ci-dessus pour la liste.

La fonction :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function RechercherVetosID ($id_vetos, $conn) {
	$vetos=mysqli_query($conn, "SELECT vetos_id, vetos_nom, vetos_prenom, vetos_ville, vetos_actif , id_postal, full_postal 
		FROM 03_chien_vetos v 
		LEFT JOIN 02_prop_postal p ON v.vetos_ville=p.id_postal 
		WHERE vetos_id='$id_vetos'");
	while ($in= mysqli_fetch_array($vetos)) {
		$vetos_id_db=$in['vetos_id'];
		$vetos_nom=$in['vetos_nom'];
		$vetos_prenom=$in['vetos_prenom'];
		$vetos_full_postal=$in['full_postal'];
		$vetos_postal=$in['vetos_ville'];
		$vetos_actif=$in['vetos_actif'];
 
		$array_vetos=array($vetos_id_db,$vetos_nom,$vetos_prenom,$vetos_postal,$vetos_full_postal,$vetos_actif);
	}
	return ($array_vetos); // ----- 0: ID véto - 1: Nom - 2: Prénom - 3: ID postal - 4: Full postal - 5: Véto actif
}

[sabotage]

Tu réponds toi même à la question : faut-il lire les données dont on n'en a pas besoin ?
Une base de donnée est faite pour être interrogée, ce n'est pas un stockage mort.
De même l'utilisateur a t'il besoin d'une liste de 1000 lignes ? Il vaut mieux utiliser des filtres et éventuellement une pagination.

[ddaweb]

Tu réponds toi même à la question : faut-il lire les données dont on n'en a pas besoin ?
Une base de donnée est faite pour être interrogée, ce n'est pas un stockage mort.
De même l'utilisateur a t'il besoin d'une liste de 1000 lignes ? Il vaut mieux utiliser des filtres et éventuellement une pagination.

Cette interface web est la gestion complète des cours de notre club de chien, un mini SAP qui gère les membres, les chiens, les cours et la comptabilité.

A plusieurs endroits je suis susceptible de consulter les données et ne concerne pas qu'un seul membre, mais le membre sur lequel on travaille.

Vu le nombre de requêtes que je fais, je me posais la question si cela ne serait pas plus intéressant de mettre en array les valeurs régulièrement utilisées avant même de passer à la page de gestion (c'est à dire au login) et donc de les réutiliser au besoin au lieu de faire une requête à chaque fois (une façon de faire une table temporaire) ?
Cet array ne contient pas toutes les valeurs des tables qui le construit (je ne mets en array que ce que j'ai besoin pour la gestion).

Actuellement, c'est le mode requête qui est utilisé, je cherche à rendre l'affichage de la page plus rapide possible en optimisant mon code et requête au maximum ... mais je ne suis qu'un novice en PHP - MySQL.
L'optimisation des requêtes a déjà eu un effet visible, je profite que je réécrit tout pour utiliser d'autres méthodes.

[sabotage]

Tu devrais alors peut être plutôt t'interesser à Ajax qui te permet de ne pas recharger la page complète mais seulement certains éléments.
Par exemple, tu interroges la bdd pour avoir les informations d'un chien mais ta liste de vétérinaire en dessous ne change pas.

[ddaweb]

Tu devrais alors peut être plutôt t'interesser à Ajax qui te permet de ne pas recharger la page complète mais seulement certains éléments.
Par exemple, tu interroges la bdd pour avoir les informations d'un chien mais ta liste de vétérinaire en dessous ne change pas.

J'avoue que ajax ou jquery sera la future évolution, mais je dois encore apprendre

Ici c'est pour mettre en mémoire des valeurs qui seront utilisées soit pour une seule valeur, soit pour faire une liste déroulante de toutes les valeurs pour faire une modification sur un membre ou chien suivant les cas.
On a écrit ensemble ... loool : non la liste des vétérinaires ne change pas, éventuellement on peut y ajouter un nouveau, je réécrirais cette ligne dans le array.

C'est juste une question de performance d'affichage de la page, en tenant compte des éventuels problèmes de mémoire utilisée par le serveur.
Lire un array est-il plus rapide que de faire la requête, surtout qu'il y a de 1.000 à 2.000 lignes à afficher pour la liste déroulante ?

[sabotage]

Les performances doivent être sensiblement les mêmes. Ca serait de la fausse optimisation alors qu'il y a beaucoup plus a gagner avec Ajax.

[ddaweb]

Les performances doivent être sensiblement les mêmes. Ca serait de la fausse optimisation alors qu'il y a beaucoup plus a gagner avec Ajax.

Si rien ne change dans les performances, je ne vais pas me casser la tête à modifier mon code qui fonctionne déjà correctement

Concernant l'ajax, je ne vais pas encore m'en occuper car je dois faire la nouvelle version avec modification profonde des tables avant janvier 2016 : c'est déjà un gros boulot, surtout refaire les nouvelles tables à partir de tables existantes sans pertes de données.
J'ai des tables par années avec des données pour la même chose dans plusieurs tables : ex. : paiement liquide - paiement banque ou cours payé - cours par abonnement.
Vu le nombre d'enregistrements possible par table, je vais fusionner tout en une seule table : la plus grosse table fera + de 30.000 enregistrements sur 5 ans (je vais devoir prévoir une purge suivant le nombre d'année que l'on doit conserver la comptabilité, juste prévoir un ID auto incrément assez élevé).
Quand j'ai commencé mes connaissance étaient tellement faible que j'ai fait beaucoup de bêtises, ce que j'essaie de redresser car c'est devenu ingérable maintenant avec l'évolution de notre club ces dernières années. Je dois faire des modifications à la main dans la BDD, maintenant tout devra se faire via l'interface web : je ne suis pas éternel pour cette gestion .

Si j'ai bien lu sur le net, une table MySQL peut facilement faire 100.000 lignes : tu confirmes ?

[rawsrc]

Salut,

euh 100 000 lignes pour un moteur de base de données, c'est comment dire... de la rigolade.
Même plusieurs dizaines de millions, ça se gère très bien sans être obligé de mettre les mains dans le cambouis.

[Tsilefy]

Une base de données est une structure écrite et optimisée spécialement pour le l'écriture, le stockage et la lecture de données. En passant ces données en session, tu ne fais que réécrire ce même système de manière suboptimale (et potentiellement dangereuse suivant le type de sécurité de ton hébergement). Si tes sessions sont stockées dans des fichiers, le temps de lecture/écriture des données dans ton fichier ne sera pas plus rapide (et peut-être plus lent, il faudrait faire des tests pour vérifier), et si tes sessions sont stockées dans la base de données, alors ce serait le comble ... tu sors des données structurées de ta base pour les re-stocker dans ta base en données non structurées.

Sans compter que si tes données dont mises à jour, ton tableau en session contiendrait des données obsolètes, ce qui entraîne des bugs en tous genres.

La seule solution qui serait plus performante serait si tes sessions sont stockées dans la RAM et que tu fasses bien attention à n'y stocker que des données "fraîches", mais dans un hébergement mutualisé ça ne se fait pas.

Bref, comme les autres l'ont dit, 1) mauvaise idée; 2) réorganise ton code, choisis mieux tes données et pagines; et 3) utilise Ajax pour charger progressivement les données.

[ddaweb]

Super, j'ai la réponse à ma question de départ : pas de session !
... et je suis partant pour fusionner les tables par année en une seule table (ceci va grandement me facilité la tâche !!)

Même si le post est résolu, il reste un point de réponse où je ne suis pas sûr de comprendre :

Il vaut mieux utiliser des filtres et éventuellement une pagination ou choisis mieux tes données et pagines

Dans les reqêtes je fais ceci :
- ne choisir que les champs que je vais utiliser (pas mettre " * ", sauf si la grande majorité des champs sont nécessaires)
- mettre un WHERE qui limite la recherche sur ce que j'ai besoin, en général un ID indexé, ou alors un autre champs indexé également (que peu de recherche se font sur un champs nom indexé par l'utilisation très sporadique)
- le 1er WHERE donne le plus de résultats, le second diminue le nombre d'avant et ainsi de suite (ordre décroissant de résultats donc)

Est-ce cela que cela veut dire ?
C'est surtout la pagination que je ne comprend pas

[ddaweb]

et potentiellement dangereuse suivant le type de sécurité de ton hébergement

Ceci a été un grand problème pour moi, j'ai fais le maximum pour éviter les problèmes en fonction de ce que j'en ai lu : est-ce sécurisé d'une façon optimum, je n'en sais rien !

Je pars d'une page de login -> une page de contrôle (mise en session d'un login OK depuis la table des données des login, si pas OK, retour page login) -> si OK : vers le site où je revérifie la session login OK (sinon retour première page pour s'identifier = accès par l'url directement).

Voici le code de vérification :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
$login = mysqli_real_escape_string($conn, htmlspecialchars($_POST['login']));
$pw = mysqli_real_escape_string($conn, htmlspecialchars($_POST['pw']));
 
// ----- Lecture de la BDD
// ----- Redirection vers le site
header('Location: index_2.php'); // ----- accès au site

Est-ce bien comme cela qu'il faut faire ?

On peut monter le niveau avec l'HTTPS, mais le club ne veut pas investir sur ce sujet malheuresement (50 € HTVA / an pour un certificat OVH)

Sur le site, tout le monde n'a pas accès à toutes les pages, des droits stocké dans une table, relu à chaque chargement de page.

[sabotage]

htmlspecialchars() n'est pas utile ici.
Sinon c'est difficile de juger de la sécurité de ton authentification avec si peu d'éléments.

Pour https c'est sûrement exagéré.

[ddaweb]

htmlspecialchars() n'est pas utile ici.
Sinon c'est difficile de juger de la sécurité de ton authentification avec si peu d'éléments.

Pour https c'est sûrement exagéré.

Heuuuuu ...
L'utilisateur est le numéro de membre.
Le mot de passe est entre 8 et 12 caractères avec au moins 1 lettre et 1 chiffre, caractères spéciaux autorisés, mais pas obligatoire.

Je sais que l'idéal serait de mettre un 3me critère comme par ex. la date de naissance enregistrée à l'inscription ...
Il est clair que je pourrais également mettre un catcha ... loool
-> Cela devient de la paranoïa pour moi car nous ne sommes pas un site à gros débit (uniquement pour la gestion et les membres consulter ou modifier leur données) et le nom de domaine n'est pas connu par les robots des moteur de recherche (mit dans le header).

[Tsilefy]

C'est surtout la pagination que je ne comprend pas

Pagination veut dire au lieu d'envoyer 1000 enregistrements d'un coup, tu limites à 10 (ou 50, ou 100), tu affiches les champs, et ensuite tu charges les 10/50/100 suivants lorsque l'utilisateur clique sur "Suivant", ou fait défiler la page vers le bas (hypothèse Ajax). Ça te permet de faire plusieurs petites requêtes au lieu d'une grosse.

Ceci a été un grand problème pour moi, j'ai fais le maximum pour éviter les problèmes en fonction de ce que j'en ai lu : est-ce sécurisé d'une façon optimum, je n'en sais rien !

je parlais surtout des sessions. Si elles sont stockées dans des fichiers, et si ton hébergeur est mauvais, d'autres sites hébergés sur le même serveur peuvent lire tes sessions. Vu que tu es chez OVH, ce problème de se pose pas.

Mais puisque tu parles de la sécurité générale...

$login = mysqli_real_escape_string($conn, htmlspecialchars($_POST['login']));

- htmlspecialchars s'utilise lorsque tu veux afficher une variable, ici tu l'utilises dans une requête MySQL, donc ce n'est pas utile et peut même entraîner dans certains cas des problèmes lorsque tu veux afficher ta variable plus tard.
- Puisque tu utilises mysqli, utilise les requêtes préparées plutôt que mysqli_real_escape_string.

Le mot de passe est entre 8 et 12 caractères avec au moins 1 lettre et 1 chiffre, caractères spéciaux autorisés, mais pas obligatoire.

Tu n'as absolument aucune raison de limiter le nombre de caractère du mot de passe. Mes mots de passe font 40 caractères, et je ne suis pas le seul, tous ceux qui utilisent des gestionnaires de mots de passe font pareil. Si tu es obligé de limiter le mot de passe, c'est que tu ne le hashes pas (avec password_hash()). Même avec des techniques de hash obsolètes comme md5 ou Sha, la limitation ne s'impose pas. Ne me dis pas que tu stockes les mots de passe en clair ou (c'est pareil) en chiffrement réversible?

Cela devient de la paranoïa pour moi car nous ne sommes pas un site à gros débit (uniquement pour la gestion et les membres consulter ou modifier leur données) et le nom de domaine n'est pas connu par les robots des moteur de recherche

Tous les sites sont susceptibles de se faire attaquer, quelque soit le nombre de visiteurs, référencé ou pas. Ceci dit, je crois qu'OVH a un système en amont pour détecter les attaques. Ce qui n'est pas une raison pour les négliger. La paranoia doit être la norme quand tu gères un site web.

[ddaweb]

Pagination veut dire au lieu d'envoyer 1000 enregistrements d'un coup, tu limites à 10 (ou 50, ou 100), tu affiches les champs, et ensuite tu charges les 10/50/100 suivants lorsque l'utilisateur clique sur "Suivant", ou fait défiler la page vers le bas (hypothèse Ajax). Ça te permet de faire plusieurs petites requêtes au lieu d'une grosse.

Quand je ferai du AJAX, le choix déroulant sera filtré avec les caractères introduits.

Puisque tu utilises mysqli, utilise les requêtes préparées plutôt que mysqli_real_escape_string.

Je dois passer à mysqli car le PHP 5.6 ne va plus accepter mysql. Je suis resté à PHP 5.5 où les fonctions mysql sont annoncée comme obsolètes hors mode de production.
Je convertis le site en mysqli et découvre cette nouvelle manière de faire.
Peux-tu me dire quelle requête préparée ?

Si tu es obligé de limiter le mot de passe, c'est que tu ne le hashes pas (avec password_hash())

Le comptage se fait sur le POST ... mais non d'une pipe, à la mise en service du site il y a plusieurs année (encore MD5) j'ai reporter cela durant les tests et comme cela arrive quand on reporte, on oublie de le faire (c'est un champs que je ne contrôle jamais dans la DB, sinon je l'aurais remarqué).
Comme je dois repasser sur toutes les pages, je vais (enfin) l'implémenter.

[Tsilefy]

Peux-tu me dire quelle requête préparée ?

Cherche "requêtes préparées" sur Google et tu tomberas sur des centaines de tutoriaux. Le principe de base consiste à envoyer les requêtes MySQL et les variables séparément, ce qui évite d'avoir à échapper manuellement toutes les variables (* sauf les noms de colonnes et les tables, qui doivent être vérifiées manuellement).

Le comptage se fait sur le POST ... mais non d'une pipe, à la mise en service du site il y a plusieurs année (encore MD5) j'ai reporter cela durant les tests et comme cela arrive quand on reporte, on oublie de le faire (c'est un champs que je ne contrôle jamais dans la DB, sinon je l'aurais remarqué).
Comme je dois repasser sur toutes les pages, je vais (enfin) l'implémenter.

Même en MD5, il n'y a pas de nécessité à limiter le nombre de caractères. Encore moins avec password_hash() :-)

[ddaweb]

Comme le post est résolu depuis un certains temps, je vais le mettre en résolu.

La discutions après a été intéressante, mais un moment donné il faut se dire qu'il existe des autres posts plus ad-hoc pour la continuer.

Merci à tous pour vos réponses