pourquoi "SELECT count(*) as nb .." renvoie un string ?

Bonjour,

Je m'essaie au PDO & singleton avec cette class.

Code:

---

1 2 3 4 5 6 7

$db1 = Outils_Bd::getInstance()->getConnexion(DSN_DATA, USER_DATA, PASS_DATA); $stmt=$db1->prepare("SELECT count(*) as nb FROM membres WHERE mb_login =:login"); $stmt->bindparam(':login', $login, PDO::PARAM_STR); $stmt->execute(); $result = $stmt->fetch(PDO::FETCH_ASSOC); // retourne un string $stmt = NULL; var_dump($result);

---

et j'obtiens :

Code:

---

1 2	array 'nb' => string '1' (length=1)

---

Pourquoi 'nb' retourne une chaîne de caractère et non un entier ?

merci

Parce que tout (à l'exception de null) ce qui provient d'une requête est interprété comme une chaine de caractères par PHP.

Utilise le typecasting pour avoir des entiers:

Code:

---

1 2	$count = (int)$row['nb'];

---

Des questions ?

merci, j'avais oublié ce principe (ou je ne l'ai jamais su :roll:).

Citation:

---

Envoyé par berlo44

Je m'essaie au PDO & singleton

---

PDO a la solution pour faire un count(). http://fr.php.net/manual/fr/pdostatement.rowcount.php

Ton code deviendrait :

Code:

---

1 2 3 4 5 6 7

$db1 = Outils_Bd::getInstance()->getConnexion(DSN_DATA, USER_DATA, PASS_DATA); $stmt=$db1->prepare("SELECT * as nb FROM membres WHERE mb_login =:login"); $stmt->bindparam(':login', $login, PDO::PARAM_STR); $stmt->execute(); $result = $stmt->rowCount(); // retourne un int $stmt = NULL; var_dump($result);

---

De toute façon tu t'en fiche pas mal du type de tes variables, PHP est typé faible:

Code:

---

1 2 3

$a = 1 + 1.0 + "1" + "1.0" echo $a; // 4

---

@Shikiryu
Ce serait tout de même bien moins performant. Dans le cas d'une table contenant un million de n-uplet tu les chargeraient tous en mémoire, alors qu'une requête count faite en SQL ne ferrai que les parcourir et les compter sans les charger en mémoire (puisqu'aucun retour n'est demandé de ces n-uplets).

Citation:

---

Envoyé par Benjamin Delespierre

De toute façon tu t'en fiche pas mal du type de tes variables, PHP est typé faible:

Code:

---

1 2 3

$a = 1 + 1.0 + "1" + "1.0" echo $a; // 4

---

---

Je sais pas si c'est un bon conseil. C'est autant une des forces qu'une des faiblesse du php. Si une erreur survient dans sa requête, rien n'est contrôlé ici (ni les erreurs, ni le type de retour), tu recevras un booléen (false) qui avec ton caste en int donnera 0... bof bof.

Citation:

---

Envoyé par transgohan

@Shikiryu
Ce serait tout de même bien moins performant. Dans le cas d'une table contenant un million de n-uplet tu les chargeraient tous en mémoire, alors qu'une requête count faite en SQL ne ferrai que les parcourir et les compter sans les charger en mémoire (puisqu'aucun retour n'est demandé de ces n-uplets).

---

Tout dépend du use-case (ici non indiqué). Souvent, quand on veut connaitre le nombre de lignes d'un SELECT, on veut aussi une liste d'éléments.
Puis, si cette requête est souvent appelée, même avec un count(*), elle sera laborieuse. Dans ce cadre là, je passerai par un cache de la requête ou par une vue statistique.

Mais quoi qu'il arrive, je viens de bien relire le manuel et quelque chose me semblant acquis est erroné : Il faut éviter d'utiliser rowCount() dans les requêtes type SELECT (dixit http://www.php.net/manual/fr/pdostatement.rowcount.php)

Il est beaucoup plus utile dans le cadre d'un UPDATE / INSERT / DELETE pour connaitre le nombre de lignes affectées par la dernière requête. (et donc faire des vérifications sécuritaires ou de l'affichage)

Enfin, quoi qu'il arrive même si

Code:

---

$result = (int)$stmt->fetch(PDO::FETCH_ASSOC);

---

fonctionne, il serait judicieux de vérifier d'abord si execute() ne retourne pas d'erreur (et la même pour le fetch())

Citation:

---

Je sais pas si c'est un bon conseil. C'est autant une des forces qu'une des faiblesse du php. Si une erreur survient dans sa requête, rien n'est contrôlé ici (ni les erreurs, ni le type de retour), tu recevras un booléen (false) qui avec ton caste en int donnera 0... bof bof.

---

Bien entendu qu'il faut contrôler, ça paraît évident. Mais pour les types de variables, ça ne sert pas à grand chose de les caster, c'est ce que j'ai voulu dire. Seuls ceux qui ont le luxe de pouvoir installer la PECL SplTypes peuvent s'affranchir de cette contrainte de types en utilisant les wrappers.

Citation:

---

Envoyé par Benjamin Delespierre

Seuls ceux qui ont le luxe de pouvoir installer la PECL SplTypes peuvent s'affranchir de cette contrainte de types en utilisant les wrappers.

---

moi moi :mrgreen::mrgreen:


tien cadeau ;) (pour version 5.3)