Discussion :

[Thorna]

Bonjour.
Dans le cadre du développement d'un petit jeu "just for fun", nous avons décidé de séparer le serveur d'authentification, le serveur de jeu et le serveur de BDD. Et contrairement à ce qu'on trouve dans beaucoup de code sur internet, nous ne voulons pas que le serveur d'authentification/de jeu construise pas à pas ses requêtes (du genre req = "SELECT * FROM " + variableTable + "WHERE truc = " + variableCond1 + " AND chose = " + variableCond2), mais plutôt passe au serveur de BDD une commande du genre "requête_n°3, variableTable, variableCond1, variableCond2" (il n'y a guère qu'une quinzaine de requêtes courantes utilisées très souvent en général).
A votre avis, vaut-il mieux que le serveur de BDD :
- reconstuise lui-même ce genre de requête à chaque fois, par exemple en remplaçant dans une requête modèle les variables par leur contenu (remplacement de texte dans une chaine) ?
- utilise des instructions préparées ?
- utilise des procédures stockées (et sont-elles préparables ?) ?
Merci !
T.

[CinePhil]

du genre req = "SELECT * FROM " + variableTable + "WHERE truc = " + variableCond1 + " AND chose = " + variableCond2

1) Il vaut mieux éviter la guerre des étoiles !

2) Je n'ai jamais compris l'intérêt d'utiliser des variables pour les noms de table et de colonnes dans la construction d'une requête qui est de toute façon spécifique au besoin précis au morceau de code applicatif.
Par exemple, si la méthode d'authentification est dans une classe Utilisateur, je trouve plus clair et plus facile d'écrire directement la requête SQL dans le code applicatif, du genre :

Code PHP :

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
	/**
	 * Récupère les informations de l'utilisateur
	 * @param string $login
	 * @return \PDOStatement
	 */
	public function getUserByLogin($login)
	{
 
		$sql = "
			SELECT userId, userValide, userNom, userPrenom, userLdap
			FROM v_utilisateur
			WHERE userLogin = :login
		";
 
		$result = $this->executerRequete($sql, array(array('param'=>':login', 'value'=>$login, 'data_type'=>PDO::PARAM_STR)));
 
		if(!empty($result))
		{
			$this->setIdentifiant(intval($result[0]['userId']));
			$this->setNomUsuel($result[0]['userNom']);
			$this->setPrenom($result[0]['userPrenom']);
			$this->setUtiValide(intval($result[0]['userValide']));
			$this->setUtiLdap(intval($result[0]['userLdap']));
		}
 
		return $result;
	}

Dans mon code, v_utilisateur est une vue qui rassemble les informations d'un utilisateur à partir des différentes tables où sont stockées les informations (table des personnes, des personnes physiques, des utilisateurs).

Comme l'authentification se fera toujours sur cette vue, à quoi ça servirait d'utiliser une variable à la place de v_utilisateur ?


Bref, j'ai l'impression que vous vous compliquez inutilement la vie !

[SQLpro]

PostgreSQL ne met pas en cache les requêtes ah-hoc qui sont envoyées directement par l'application cliente. Pour forcer la mise en cache des plans de requêtes et donc leur réutilisation (ce qui permet de gagner du temps) il faut accepter d'en perdre en demandant un "prepare" qui envoie une première fois la requête pour établir un plan consigné puis exécuter la requête qui va reprendre le plan consigné.

En revanche en utilisant des fonctions (il n'y a pas de procédure dans PostgreSQL) la mise en cache des plans de requête est automatique.

Donc, oui, ce sera plus intéressant d'un point de vue sécurité et performances.

A +

[Thorna]

@Cinephil: j'ai écrit ma ligne d'exemple en vitesse sans trop réfléchir et je le regrette: il n'a jamais été question de mettre un nom de table en variable ! Ca m'apprendra à ne relire que les phrases, pas les exemples !
@SQLPro : il me semblait bien avoir lu quelque part qu'une mise en cache se faisait automatiquement mais je n'avais pas retrouvé dans quelles circonstances. Allons-y donc pour les fonctions, ce qui me semblait d'ailleurs mieux organisé et plus simple d'emploi !

Merci à vous !

[SQLpro]

Il y a plusieurs states de cache dans un SGBDR. Par exemple dans SQL Server il y en a une centaine... Les principales sont :
1) les données
2) les procédures (ou fonctions dans le cas de PG)
3) les plan d'exécution
...
Le but étant de réutiliser plutôt que de reconstruire.
PG fait essentiellement les deux et le 3e uniquement si :
1) la requête ad hoc est préparée
2) la requête est incluse dans une routine SQL (fonction dans PG).

Le cache étant géré par un algorithme de la famille LRU (Least Recently Use)

A +