Forum d'entraide PHPFrance

Bonjour je souhaiterais avoir un peu d 'aide pour créer 2 Array.

Voici ma table

CREATE TABLE IF NOT EXISTS `croissance` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`n_ident` text NOT NULL,
`poids` int(11) DEFAULT NULL,
`longueur` int(11) DEFAULT NULL,
`largeur` int(11) DEFAULT NULL,
`hauteur` int(11) DEFAULT NULL,
`mue` enum('oui','non') DEFAULT NULL,
`date` date NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=4 ;

de cette table je dois recuperer 2 tableaux

$ydata = array ( poids);
$xdata = array ('date');

filtrer par n_ident (ma variable de comparaison est = $row_DetailRS1['n_ident']

Dans ma table au niveau du champ poids, il va m'arriver que celui ci soit vide, donc il ne faut pas que la fonction inclue la date et le poids de cette table.

Quelqu'un pourrait me donner un coup de main SVP

Salut,

Quelque chose comme ceci :

Exemple:

$sql= " SELECT poids, date FROM croissance WHERE poids != 'NULL' ";
  $req = mysql_query($sql) or die('<p>Erreur SQL !'.$sql.mysql_error().'</p>');
  
  
  WHILE ($row = mysql_fetch_array($req))
  {
  	$ydata[] = $row['poids'];
  	$xdata[] = $row['date'];
  }

Merci ca marche a merveille

Salut,

Quelque chose comme ceci :

Exemple:

$sql= " SELECT poids, date FROM croissance WHERE poids != 'NULL' ";
  $req = mysql_query($sql) or die('<p>Erreur SQL !'.$sql.mysql_error().'</p>');
  
  
  WHILE ($row = mysql_fetch_array($req))
  {
  	$ydata[] = $row['poids'];
  	$xdata[] = $row['date'];
  }

Je sais pas mais, faudrait peut-être penser à ne plus induire les gens en erreur en proposant des solutions se basant sur l'extension dépréciée MySQL, non ?

Je sais pas mais, faudrait peut-être penser à ne plus induire les gens en erreur en proposant des solutions se basant sur l'extension dépréciée MySQL, non ?

Autant pour moi, je ne le savais pas, je ne l'utilise plus depuis longtemps.
Ceci dit a lui d’adapter la solution ou libre à toi d'en proposer une autre

Je sais pas mais, faudrait peut-être penser à ne plus induire les gens en erreur en proposant des solutions se basant sur l'extension dépréciée MySQL, non ?

On s'en tape un peu, c'est un exemple générique.
A mon avis cela va durer encore longtemps simplement parce que l'ancienne extension est la plus rapide à écrire et donc plus rapide pour donner des exemples. Reste ensuite à adapter le code à l'extension réellement utilisée. Imagine le boulot si on devait donner des exemples avec mysqli + pdo sans compter que pour les débutants ce serait peut-être incompréhensible...
Pour résumé c'est aux utilisateurs que tu dois donner le conseil de si possible (car par exemple mysqli ou pdo ne sont pas encore disponibles chez tous les hébergeurs) ne plus utiliser l'extension mysql, pas à ceux qui donnent le principe du code. A moins que tu n'aies une solution standard à proposer...

=D>

Je sais pas mais, faudrait peut-être penser à ne plus induire les gens en erreur en proposant des solutions se basant sur l'extension dépréciée MySQL, non ?

On s'en tape un peu, c'est un exemple générique.
A mon avis cela va durer encore longtemps simplement parce que l'ancienne extension est la plus rapide à écrire et donc plus rapide pour donner des exemples. Reste ensuite à adapter le code à l'extension réellement utilisée. Imagine le boulot si on devait donner des exemples avec mysqli + pdo sans compter que pour les débutants ce serait peut-être incompréhensible...
Pour résumé c'est aux utilisateurs que tu dois donner le conseil de si possible (car par exemple mysqli ou pdo ne sont pas encore disponibles chez tous les hébergeurs) ne plus utiliser l'extension mysql, pas à ceux qui donnent le principe du code. A moins que tu n'aies une solution standard à proposer...

Non, je pense que donner des mauvais exemples est contreproductif. Du code écrit avec PDO est aussi vite écrit qu'avec l'extension MySQL et montre bien qu'il ne faut pas utiliser MySQL.

Non, je pense que donner des mauvais exemples est contreproductif. Du code écrit avec PDO est aussi vite écrit qu'avec l'extension MySQL et montre bien qu'il ne faut pas utiliser MySQL.

Le mot "contreproductif" n'est pas adapté dans ce contexte.

Pour être productif dans un forum d'entraide on commence par répondre à la question posée de manière compréhensible. Rien ne t'empêche ensuite de préciser les meilleures méthodes mais en complément, car si le prérequis pour comprendre ta réponse est totalement inconnu pour la personne que tu es censée aider c'est la réponse elle même qui est contre productive car inaccessible. Il en serait autrement pour un utilisateur avancé, mais au vu de la question initiale ce n'est évidemment pas le cas.

Par ailleurs, la grande majorité des débutants commencent par développer un site avec l'hébergement que propose leur FAI. Donc si l'on imposait telle ou telle "nouvelle" extension en tant que modèle encore faudrait-il s'assurer que celle-ci soit supportée par tous ces hébergeurs gratuits. As-tu vérifié si c'est le cas ? Sinon un exemple impossible à mettre en place est pour le moins contre productif.

Il faut bien distinguer deux choses : les exemples de requêtes et l'extension utilisée. Autrement tu courre après deux lièvres à la fois ce qui est très souvent contre productif, enfin bon tu verras à l'usage. En l'occurrence ici il s'agissait de construire un tableau...

Enfin sur le fond, que tu ajoute un message pour dire qu'il vaut mieux éviter si possible d'utiliser l'extension mysql serait tout à fait approprié. Mais sur la forme, la façon de t'y prendre est pour le moins maladroite, voire contre productive

Ah mais oui, je ne partais évidemment pas du principe que quelqu'un possède un hébergement avec PHP3. Je parle de versions de PHP qui sont encore officiellement supportées.
Le support pour PHP5.2 a officiellement été suspendu il y a maintenant un peu plus d'un an et l'avertissement qu'il ne faut surtout pas utiliser MySQL comme extension pour MySQL est marqué en rouge sur la documentation depuis à peu près un an aussi.
Je pars du principe qu'il faut vivre avec son temps. Je ne pars plus du principe qu'on utilise encore les quotes magiques, que register globals est activé et j'ose même partir du principe que les variables globales de PHP existent début 2013 dans les version de PHP utilisées en 2013.
Le mot contreproductif est employé d'un point de vue de celui qui reçoit l'aide. En ne lui indiquant pas que le code qu'on lui donne est dorénavant faux et générera des messages d'erreur, il va croire que c'est du bon code venant de quelqu'un qui sait de quoi il parle (ben oui, vu que ça marche maintenant). Et non seulement lui sera embêté dans trois ans, mais aussi tous les messages dans ce genre pollueront Google quand la version 5.6 ou 6 sera la version la plus utilisée.

Ce que je fais quand j'aide directement quelqu'un, c'est de donner la réponse à sa question tout en lui expliquant - en même temps - qu'il se base sur quelque chose de mauvais, sur quelque chose dont l'utilisation est officiellement découragée. Ce n'est pas contreproductif, même si de toute évidence, je suis la seule à me préoccuper de ce genre de problèmes. En tout cas, c'est ce genre de position qui a fait en sorte que l'équipe PHP a repoussé et repoussé la date pour jeter par dessus bord cette extension et pas mal d'autres.

Par ailleurs, la grande majorité des débutants commencent par développer un site avec l'hébergement que propose leur FAI. Donc si l'on imposait telle ou telle "nouvelle" extension en tant que modèle encore faudrait-il s'assurer que celle-ci soit supportée par tous ces hébergeurs gratuits. As-tu vérifié si c'est le cas ? Sinon un exemple impossible à mettre en place est pour le moins contre productif.

Ce n'est pas parce que la majorité des débutants font mal les choses qu'il faut les encourager à les faire. Dorénavant, c'est PHP qui imposera le bon style de code, ce n'est pas moi - même si sur divers forums où je suis active, ça fait deux ans que j'avertis systématiquement les gens de ne plus utiliser cette extension. Mais celui-ci est le premier où on est aussi farouchement opposé de s'adapter à l'avenir.

Par ailleurs, la grande majorité des débutants commencent par développer un site avec l'hébergement que propose leur FAI. Donc si l'on imposait telle ou telle "nouvelle" extension en tant que modèle encore faudrait-il s'assurer que celle-ci soit supportée par tous ces hébergeurs gratuits. As-tu vérifié si c'est le cas ? Sinon un exemple impossible à mettre en place est pour le moins contre productif.

Ce n'est pas parce que la majorité des débutants font mal les choses qu'il faut les encourager à les faire.

Les débutants font avec les outils qu'ils ont à leur disposition. Si PDO n'est pas activé sur leur serveur ce n'est pas leur choix et l'on est bien obligé de faire avec pour leur permettre de progresser dans leur code.

Dorénavant, c'est PHP qui imposera le bon style de code, ce n'est pas moi - même si sur divers forums où je suis active, ça fait deux ans que j'avertis systématiquement les gens de ne plus utiliser cette extension. Mais celui-ci est le premier où on est aussi farouchement opposé de s'adapter à l'avenir.

Regarde la date de ce message, il a presque trois ans...

Tu as oublié ma dernière remarque concernant le fond et la forme.
Personne ne va contester qu'il vaut mieux éviter d'utiliser une extension obsolète en php 5.5. Ce n'était simplement pas le sujet ici, mais que tu ajoute un message pour prévenir l'utilisateur d'utiliser si possible mysqli ou pdo aurait été bien venu. Par contre ta manière de le faire en citant le message de Dunbar avec comme mention "Je sais pas mais, faudrait peut-être penser à ne plus induire les gens en erreur en proposant des solutions se basant sur l'extension dépréciée MySQL, non ?" n'est utile que pour flatter ton égo, car en faisant ainsi tu n'informe personne et ne propose aucune solution.

Vu qu'on a carrément déraper, je vais en profiter pour poser 2 petites questions qui feront avancer peut-être les choses .
Est-ce qu'il y a eu des failles détectées sous mysql_real_escape_string?
Est-ce que mysqli_real_escape_string() équivaut à un prepare PDO? Si non, lequel est le plus puissant?

Merci.

Vu qu'on a carrément déraper, je vais en profiter pour poser 2 petites questions qui feront avancer peut-être les choses .
Est-ce qu'il y a eu des failles détectées sous mysql_real_escape_string?
Est-ce que mysqli_real_escape_string() équivaut à un prepare PDO? Si non, lequel est le plus puissant?

Merci.

Ce serait mieux d'ouvrir un autre sujet.
Basiquement mysql_real_escape_string est inefficace si tu fais ça :

$sql = "SELECT * FROM toto WHERE id=".mysql_real_escape_string($_GET['titi']);

Il faut toujours entourer par des quotes ou doubles quotes par exemple :

$sql = "SELECT * FROM toto WHERE id='".mysql_real_escape_string($_GET['titi'])."'";

Concernant mysqli et pdo
- mysqli_real_escape_string() est l'équivalent de la méthode quote de pdo
- mysqli_prepare en mode procédural ou $mysqli->prepare en mode objet sont l'équivalent de la méthode $pdo->prepare de PDO

La préparation d'une requête demande toujours un peu plus de temps (niveau serveur et écriture du code). Initialement les requêtes préparées ont été prévues pour accélérer le temps de traitement sur des requêtes multiples (typiquement dans une boucle). On les utilise aussi souvent pour mieux sécuriser des données sensibles impossibles à contrôler car l'isolation des variables est mieux assurée par le bind.

Ok donc si mysql_real_escape_string n'a pas de failles et les mysqli_* sont équivalents (niveau sécu) à la PDO, il n'y a donc pas de soucis à utiliser les mysql_* pour les explications.
Par contre, comme proposé Perine (même si la façon de le dire n’était pas top), il serait bien d'indiquer que les mysql_* sont obsolètes (voire pourquoi pas faire 1 épinglé avec les équivalences mysql_*, mysqli_*, PDO). Comme ça tout le monde est content

Par contre, comme proposé Perine (même si la façon de le dire n’était pas top), il serait bien d'indiquer que les mysql_* sont obsolètes (voire pourquoi pas faire 1 épinglé avec les équivalences mysql_*, mysqli_*, PDO). Comme ça tout le monde est content

Bah on en parlait surtout quand la doc php n'était pas à jour. Mais cela fait maintenant plusieurs mois que des encadrés sont dans toutes les fonctions mysql, alors on a baissé un peu la garde. Normalement on est là pour donner des exemples qui complètent ou qui expliquent un peu la doc mais pas pour s'y substituer. Après les débutants qui ne regardent jamais la doc resteront à jamais des débutants et ils auront les mêmes résultats que tous ceux qui font un truc occasionnel à l'arrache, c'est à dire ni optimisé ni pérenne (et ça vaut dans tous les domaines).

Ensuite si l'on donne parfois encore des exemples avec l'ancienne extension c'est simplement parce que c'est ce qui est toujours actuellement le plus connu.
Par exemple, si dunbar avait donné une syntaxe pdo on avait deux chances sur trois d'avoir en réponse "c'est quoi ça ?". Ensuite de donner un lien vers la doc, puis de re préciser "si tu ne connais pas poo utilises plutôt mysqli qui propose une transition plus facile en procédural". Et pour peu que le débutant soit sur un hébergement amateur (ce qui est souvent le cas quand on débute), ben c'est retour à la case départ car il est très possible que ni l'une ni l'autre des extensions ne soit installée, avec en prime pas mal de temps perdu pour tout le monde. On connaît ce manège par coeur et à la longue c'est fatiguant. L'ancienne extension est plus universelle dans le sens où ceux qui utilisent pdo ou mysqli auront vite fait de faire les adaptations nécessaires. Et pour les débutants qui n'ont pas la motivation nécessaire pour regarder au moins une fois la doc, c'est leur problème.

Cela dit, comme tu l'as compris, on a rien contre ceux qui font une piqure de rappel sur les bonnes extensions à utiliser, bien au contraire. Ce n'est pas parce qu'on est fatigué de rabâcher toujours la même chose qu'on va snober ceux qui ont encore l'énergie de le faire. Mais comme tu l'as compris aussi, il y a l'art et la manière de le faire. Et pour préciser ma pensée un message du type "je rappelle au passage que l'extension mysql est dépréciée, utiliser si possible pdo ou mysqli" - sans mentionner le message d'aide car ce n'était précisément pas le sujet abordé ici - aurait été le bienvenu et n'aurait suscité aucune réaction de personne