il me semble avoir vu il y a quelques temps un article qui expliquait que pour vérifier l'existence de qqch en DB il valait mieux utiliser un SELECT COUNT plutot que le num_rows de PHP.
Soit on teste par PHP soit par MYSQL.
Je ne sais pas ce que vous en pensez c'est juste pour soumettre cette idée :)
C'est surement mieux, mais ca te coutera deux requetes SQL.
Des que tu lances mysql_real_escape_string n'importe ou dans ton code, ca fait appel à mysql pour savoir ce qui doit etre escapé en fonction de l'encodage. Bref, c'est plus couteux.
En conséquences, pour utiliser mysql_real_escape_string, il faut que ta connexion mysql soit déja établi sinon tu te manges une erreur alors qu'avec mysql_escape_string non.
Apres, c'est sur, la fonction real donne de meilleurs résultats, mais c'est pas forcemment la plus pratique à utiliser (chez moi, par exemple, quand j'ecris ma requete SQL, ma connexion à MySQL n'est pas encore faite, ma connexion se fait au moment ou je lance la query dans une fonction SQL : bref, je ne peux pas utiliser cette fonction à moins de faire des trucs crades).
oui mais personnellement, la plupart des sites avec lesquels je bossent sont en MyISAM. Toi qui bosse en hébergement dans quels cas est ce que tu vois du INNODB stp ?
En gros, tu as besoin d'innod dès lors que tu fais une action sur plusieures tables via un seul script.
Grace à innodb, tu lances une transaction.
Tu fais ton insert dans la table 1.
Si ton insert plante, tu rollback la transation (et la, tu es sur que ton insert n'a pas été fait), sinon tu fais un autre insert dans la table 2. Si cette deuxieme requete fait du caca, tu rollback la transation (et la, en rollbackant, ce sont la requete 2 ET la requete 1 qui sont annulées), sinon, tu la commit.
Bref, ca permet de garder une base intègre.
Le cas typique d'utilisation : pour un forum, pour un nouveau sujet, souvent tu fais un insert dans une table sujet et une table message. En innodb, tu es assuré à 100% de ne pas avoir un sujet sans message.
