MODEL SQL AVEC MYSQLI
cs_emilia123
Messages postés
122
Date d'inscription
mercredi 19 décembre 2001
Statut
Membre
Dernière intervention
5 janvier 2009
-
10 mai 2010 à 10:56
guisx00 Messages postés 104 Date d'inscription dimanche 23 juillet 2006 Statut Membre Dernière intervention 15 août 2009 - 15 mai 2010 à 11:31
guisx00 Messages postés 104 Date d'inscription dimanche 23 juillet 2006 Statut Membre Dernière intervention 15 août 2009 - 15 mai 2010 à 11:31
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51720-model-sql-avec-mysqli
https://codes-sources.commentcamarche.net/source/51720-model-sql-avec-mysqli
15 mai 2010 à 11:31
Dsl pour la lenteur de la mise à jour du code mais j'ai été pas mal occupé c derniers jours
Alors en changement :
Ajout d'une fonction de vérification d'existance d'un enregistrement
Amélioration des structures des fonctions et de la manière dont elle sont écrite
Ajout d'une vérification de doublons au moment de l'ajout ou de la modif d'un enregistrement
(bientôt en fonction, je suis entrain d'y réfléchir)
Séparation de la fonction save en deux (une fonction pour modif et une fonction pour l'insert)
Séparation des pages insert et modif (une page avec le formulaire/une page avec le script)
A venir :
- Fonction de gestion des requêtes de différentes opération sur la table (OPTIMIZE,FLUSH,REPAIR,TRUNCATE)
- Création d'un fonction de recherche de doublons
- Mise en place d'un système de pagination pour la fonction find
- Optimisation de la rapidité d'exécution du script
Voilà déjà en gros pour les 1ère améliorations.
N'hésitez pas à me donner votre avis sur ses nouveautés et peut être vos idées d'amélioration
Bonne journée et bonne fin de week end
10 mai 2010 à 19:20
EMILIA123 :
1) oui tout à fait merci de le faire remarque. Je vais changer sa.
2) Pour la secu comme je l'es mis dans la description plus haut, je n'est pas mis les vérifications de formulaires etc. (histoire de pas file un script clé en main ^^)
3 et 4) Je comprends se que tu veux me dire je vais réfléchir à amélioré sa.
En tout cas merci pour ses quelques conseils sa va m'aide je pense. Je me tâte encore bcp sur l'utilisation d'un tel procédé pour un site.
Est-ce vraiment viable pour une structure assez conséquente ou pas ? (temps d'exécution etc)
Nashouille : Que veux tu dire par étendre l'api Mysqli ?
10 mai 2010 à 12:08
Il y a de l'idée mais c'est vue et revue dommage !
Amicalement
10 mai 2010 à 10:56
Le code est sympa, mais j'aurais fais 2 ou 3 commentaires :
1) au niveau formalisme il est conseillé (car plus rapide) d'utiliser la concaténation et les simples quotes.
ex : (ton code) "DELETE FROM ".$this->table." WHERE id=$id" (php est obligé de chercher les variables dans les " ... "
il vaudrait mieux : 'DELETE FROM '.$this->table.' WHERE id='.$id
les différents tests disponibles sur internet semblent tous montrer une rapidité plus élevée pour les ' '.$var.' '
2) au niveau fonctionnement, aucune sécurisation des données de la requete n'est effectuée.
ex pour l'update d'un enregistrement, le script appelant (modif.php) recupere le id ($id_choix_modif = $_POST["txt_id"]) et le passe directement à la fonction d'update. si l'internaute passe "1 or 1=1", toute la table va être updatée. le id étant numérique, il faudrait forcer via $id=intval($id) ou caster $id=(int)$id
le (int) est bien a d'autres endroits mais pas à celui la. cela ne couterait rien que la verif soit DANS la fonction d'update (mieux vaut le faire à l'endroit où c'est utilisé, plutôt qu'a 20 endroits et risquer l'oubli).
et pour rappel : http://www.php.net/manual/fr/mysqli.query.php indique : "Les données contenues dans la requête doivent être échappées."
3) au niveau code, dans la fonction find, si je ne passe pas de order (si il y a un test sur l'existence, c'est que je peux ne pas le passer), bin la requête ne fonctionnera plus, le texte "order by" étant toujours présent dans la requête.
4) en fait tous les tests dans la partie find() ne servent pas à grand chose dans l'état. field est obligatoire (sinon la requete plante) donc pourquoi faire un test sur le passage de cette variable, et ne rien faire si rien n'est passé?
pareil pour les conditions, si rien n'est passé, ca plante.
Il serait plus optimisé de générer un retour immédiat plutôt que de laisser tourner la fonction sachant que ca va planter.
Je n'ai fais que survoler le code, mais j'espère que cela pourra t'aider.
Cordialement,
EM.