Salut,
 
Je voudrais savoir si, pour un nouveau projet, se basant sur PHP/MySQL, il était préférable d'utiliser la librairie mysql ou la librairie mysqli?
 
Ici, je parle plus en terme de performances générales (vitesse, occupation mémoire, serveur, etc) que sur des concepts du type "mysqli, c'est mieux, car c'est orienté objet".
 
D'autre part, et dans l'hypothèse où je reste cantonné à la librairie mysql, vaut il mieux utiliser PHP v4 ou PHP v5?
 

quelle est ta version de MySQL?

Bah c'est pareil, c'est un peu à moi de choisir la version de MySQL que je veux (donc, je pense a priori que je vais prendre la dernière 4.1.x en date)

je ne peux pas te donner de certitudes mais avec la 4.1.9 couplee a php 5.0.2 j'ai d'excellentes perfs

D'accord!
 
Mais tu utilises mysql ou mysqli?
 
C'est ce que je compte utiliser: MySQL 4.1.x avec PHP 5.x (d'après tout ce que j'ai lu, PHP 5 règlke pas mal de problèmes). Par contre, je n'ose pas m'aventurer dans MySQL 5.x.

Mais ca dépends surtout de ton utilisation...

j'utilise mysql

Yoyo c'est pour faire quoi?

 
Cad?  
 
Je parle bien entendu ici d'un site web, type dynamique, permettant surtout de consulter des données, mais aussi de les mettre à jour, le tout utilisant un moteur de requêtes assez complexe...

C'est à dire assez complexe?

Bah je ne sais pas comment décrire la chose, mais ce ne sont pas des requêtes de base du genre "SELECT name FROM people WHERE nationality = 'FR'"
 
Ce que je veux dire, c'est que l'extraction de mes données nécessite pas mal de traitement, à l'aide de plusieurs requêtes, etc. imagine, par exemple, pour simplifier la chose, que tu as plusieurs villes dans ta BD, et que chaque ville est reliée à quelques voisines seulement. Et que tu veuilles aller de Paris à Limoges en utilisant le plus court chemin. Il va donc y avoir ce qu'on appelle des parcours de graphe, etc... Ce ne seront pas des jointures simples. (ce n'est qu'un exemple)
 

je fais tout ca sur de tres gros volumes sans aucun pb avec la config  decrite ci dessus

Oué je comprends.
Bah tante avec Mysql 4.1.9 et PHP 5....mais je sais pas si c'est le mieux pour ce que tu veux faire.

D'accord, je pense bien quela config dont tu me parles est appropriée, mais je me demandais, vu ce que j'ai lu dans un livre O'Reilly, quel choix effectuer entre mysql et mysqli (c'estle sujet principal du topic finalement). J'ai vu que mysqli permettait d'utiliser ds requêtes paramétrées, et dans ce que j'ai lu, il apparaît que c'est plus rapide (mais bon, je prends celà avec des pincettes, et c'est pour ça que je suis venu demander sur ce forum ce que vous en pensiez)

 
Oui, oui, mais comme dit juste plus haut, ce que je cherche, c'est savoir s'il vaut mieux pour moi utiliser mysql ou mysqli... (mysqli était une librairie d'accès MySQL plus récente et orientée objet)
 
Sinon, oncernant plus globalement les technos à utiliser, j'ai choisi MySQL car c'est rapide et Open. Et PHP, bah...j'ai lu à plusieurs reprises que c'était sans doute plus rapide que Perl et plus étendu. (mais bon, je ne cherche pas à lancer de polémique ici, je em suis lancé dans PHP un peu au hasard au début)
 

php et MySQL cherches pas y a pas de meilleure alternative l'un pour l'autre
sinon apparement mysqli (que je ne connaissait pas quand j'ai installe mon serveur il y a 6 mois ) apparait clairement etre la meilleure alternative pour une version de MySQL superieure ou egale a 4.1.3

 
C'est bien ce que j'ai lu, mais j'aurais quand même voulu qu'on me le confirme de manière ferme... et non pas parce qu'il est dit que mysqli est meilleur. Ce qui est bizarre, c'est que la plupart des livres récents traitant de PHP/MySQL ne parlent que de mysql, pas de mysqli.

je n'ai pas l'experience pour t'affirmer fermement que mysqli est meilleur que mysql

D'accord!
 
Merci pour ta contribution. Je reste donc poour le moment sur PHP 5.0.x et MySQL 4.1.x.
 
D'autres avis? (concernant mysql VS mysqli bien sûr)

Je crois même que mysqli est obligatoire pour > 4.1, non ? La 4.1 n'étant pas supportée par mysql ? (à vérifier)

Bah non, puisque plus haut, ils font du PHP 5.0.x avec du MySQL 4.1.x en utilisant mysql.
 
Pour ma part, je n'ai fait que du PHP 4.x avec du MySQL 4.1.x, en utilsant mysql.

Perso je fais maintenant du mysqli pour plus de simplicité après j'ai lu que mysql était plus rapide mais bon c pas flagrant par rapport à la simplicité

obligatoire non, mais conseillée par php.net et par mysql.com pour un serv. MySQL v4.1.3+
de toute façon tu ne bénéficis pas de toutes les possibilités de MySQL v4.1.3+ avec le client mysql_pas_i
alors bon ...
--
edit : suis encore à mysql_pas_i, qlq'un aurait un peu de temps à m'envoyer par mail  
--
re-edit : z'ai retrouvé chez php.net :
This MySQL extension doesn't support full functionality of MySQL versions greater than 4.1.0. For that, use MySQLi.

Tiens, intéressant... Le mysqli serait donc plus lent que le mysql?
 
Conclusion: si toutes les fonctionnalités dont j'ai besoin sont présentes dans mysql, autant utiliser mysql??

Perso j'utiliserai qd même mysqli c'est ce qui sera le mieux à terme. Maintenant c peut être un chouilla moins performant mais à terme ça le sera plus je pense

http://www.johnjawed.com/benchmarks/
 
Dont voilà les résultat :  
mysqli_stmt > mysql_query > mysqli_query > mysqli_multi_query

> Perso j'utiliserai qd même mysqli  
c'est que je me dis aussi ... malheureusement
--
nan ? personne n'a de temps à envoyer, aller par PM au moins ...  

Bah j'ai lu rapidement le benchmar.
 
Déja, le gars fait 1000000 fois la même requête (un INSERT de base) mais il ne lance qu'une fois le mysqli_prepare dans le cadre du mysqli_stmt, donc, c'est sûr qu'il a plus vite avec ce dernier.
 
Mais dans le cas où je dois exécuter des requêtes différentes, alors je me demande s'il resterait le plus rapide.
 
D'autre part, j'aurais aimé qu'il fasse un SELECT alambiqué pour comparer, etc...
 
Bref, je suis encore dans l'expectative finalement...

tu nous tiens au courant de tes conclusions ?

 
et concernant le bench, le point non négligeable est dans les conclusions : mysql_real_escape_string
ça mérite reflexion, enfin pour les utilisateurs de mysql_real_escape_string ... comme ouam  
marchi Je@nb pour le lien

Oui, mais pour ma part, les requêtes mySQL seront internes entre PHP et MySQL, et les paramètres seront "parsés" en amont...
 
Ca aurait vraiment été bien de faitre un comparatif sur une grosse requête. Histoire de voir si le mysqli peut rivaliser dans des conditions normales avec le mysql...

bon, prends le comme ça vient, je viens de patcher ma classe sql pour connecter "vite fait" via mysqli, et apparement je gagne en moyenne 0.004 s (sur mon vieux coucou de 700MHz) test sur 20aine de hits sur une page à 6 requêtes dont 1 insert et 1 replace le reste étant du select - truc de base quoi ...
bon ça te fait une belle jambe et je pourrais t'en raconter d'autres comme ça tu pourrais marcher    
et rien n'est optimisé pour l'utilisation de mysqli, donc bon ... c'est une maigre participation à la cause ...
dès que j'ai un peu de temps, il faut que je m'y mette sérieusement ...
a+

D'accord, merci pour le test rapide Quelque part, ça met en confiance.
(au fait, 0.004s par rapport à combien à la base?)
 
 

considères une augmentation de perf de +-8% sur MySQL v4.1.14
mais encore une fois, c'est quasi juste un mysql_* -> mysqli_*
donc sans aucun profit de fonctionnalités ...

il me semble que mysqli est optimise pour MySQL >= 4.1.3 non?
 
EDIT : +- 8% cela me parait enorme !!!
je ne vois pas de justification a cette difference ,le moteur du SGBD restant tous comptes faits le meme

je m'en rend compte, mais c'est ma constatation ...
ok c'est pas un bench super poussé, une 20aine de données seulement, mais c'est ce qu'il en sort ...

Bah surtout, ce que je me dis, c'est que 0.004s, c'est 8%, alors, ça correspond à des temps très très courts au global, dionc, c'e n'est pas assez fiable comme test. (mais bon, ça donne une idée )
 
Sinon, il me semble que 4.1.3 > 4.1.14, nan? (ça dépend si c'est classé ar ordre alphanum ou juste num)

Au boulot, on utilise mysql5 depuis quelques semaines, et si on a eu un blocage de mysql cette semaine, c'était par ce qu'on avait 5 ou 6 versions de retard.
J'utilises également mysql5 chez moi et pour des requettes classiques (select, insert, update même multi table avec des requettes imbriqués) je n'ai eu aucun plantage.
D'ailleur, la dernéire version de mysql5 n'est plus une beta mais une release candidate. D'aprés eux, les seuls bugs qui pouraient encore rester sont des bugs ne survenant que dans des situations complexes.
 
Normalement, tu ne devrais avoir aucun probléme même en utilisant mysql5, mais si tu n'utilises pas les nouveautés de mysql5, alors reste avec la version4. Nous au boulot, on est passé trés vite à la version5 pour éviter que la transition V4 vers V5 ne soit trop compliqué vu la masse de données qu'on aurait à faire transiter de l'un à l'autre : on obtient déjà un fichier de plus de 10 Go quand on exporte la base sous forme de requettes SQL et ca augmente tout le temps.

Bah j'avais regardé, mais quelles sont les nouveautés intéressantes?
 
Il me semble qu'il y a les procédures stockées, et si ça marche aussi bien que sur SQLServer, alors c'est un réel plus, car ça permet de faire beaucoup de traitement en interne (sous réserve  que le langage utilisé soit aussi évolué et rapide que Transact SQL par exemple). Mais je nme demande si tout celà est bien optimal ...

Moi, je suis passé directement de mysql4 à mysql5, donc je sais pas qu'elles sont les nouveautés par rapport à mysql4.
Mais il y a les procédure stokés qui ont l'air de bien marché même si j'ai rien fait de complexe avec.
Il y a aussi la possibilité de créer à l'intérieur d'une requette des tables temporaires à l'aide d'une requette de type "select" mis dans la partie from de la requette. (super rapide comme truc, tu gagnes beaucoup par rapport à de simples requettes imbriqués )
 
Grace aux procédures stockés, on peut limiter de maniére trés précise les droits d'accés aux données : il y a un niveau d'autorisation ou on autorise l'accés à une procédure stockés sans donner directement l'accés aux tables utilisé par la requette, la procédure stocké utilise alors les droits d'accés de son propriétaire.
 
Et il y a surement pleins d'autres trucs que j'ai pas encore découvert ou que je pense être déjà présent dans mysql 4.1 sans que ca soit le cas.

 
ben oui 4.1.3 > 4.1.14