L'objet existait déjà sous PHP4, renseigne toi...

Cette fonction est là pour trouver le prochain id, elle ne réorganise pas les enregistrements. Elle n'est donc pas à exécuter après un delete mais avant un insert.

@SuperTonic : Si tu indiques correctement les conditions, oui. C'est important (mais pas indispensable) car il permet de ne pas mobiliser plus de ressources que nécessaire. C'est de l'optimisation. Pourquoi charger en mémoire tous les enregistrements quand tu n'as besoin que des 10 premiers, ou que du 11ème au 20ème (par exemple...) ?

Le temps perdu est pour les INSERT (c'est là qu'on calcule le id, donc aussi coté utilisateurs), pas lors des delete.
Et je ne vois toujours pas pourquoi tu n'utiliserais pas between, que tu peux utiliser même en ayant des id qui ont sauté.

coucou747, le temps que tu gagnes a utiliser between au lieu de order by ... limit, tu le perds à repasser en revue toute ta table à la recherche d'un id "libéré". L'un dans l'autre, moi je préfère ne pas toucher aux clés primaires pour garder une certaine "logique de progression" dans l'enregistrement des tuples. Et puis je vois pas ce qui t'empêche d'utiliser between dans le cas où certains id ont sauté, il suffit de bien penser ton application et tes requêtes dès le départ (je te fait confiance pour ça) et ça tourne sans problème.

Je suis étonné que personne n'ai fait la remarque suivante : il ne faut surtout pas faire ce genre d'opérations quand on utilise des clés étrangères. Ca crée des conflits d'intégrité référentielle. D'ailleurs je vois toujours pas pourquoi les débutants (je parle en général, SuperTonic) cherchent toujours à combler ces "trous" dans les tables ??

Ce que t'en dis m'intéresse, sinon j'aurais pas posté mon code ici ;)

Reprenons :

Les évènements ici ne dépendent pas d'un changement d'état comme le voudrait l'Observer design pattern, un évènement peux intervenir n'importe quand, n'importe où, et sans raison. Dans ces conditions, difficile d'associer un sujet, ainsi que ses états, à un observateur précis. Moi je veux bien utiliser ce design pattern, mais faudra m'expliquer comment faire dans cette configuration...

Sinon tu as parlé à plusieurs reprises de passer en paramètre des objets plutôt que des fonctions. Vu que le but est d'appeler des fonctions, je comprend pas pourquoi utiliser des objets ?

Merci pour tes remarques.

Je me suis renseigné à propos du design pattern Observer, et ce n'est pas du tout ce que je cherche à faire. De ce que j'ai compris, il y a les sujets, et les observateurs, mais tout ça se passe à l'intérieur d'un objet. Mon objectif avec mon application/méthode c'est de pouvoir placer des évènements partout dans mon code (dans la partie "globale"), pas de gérer des évènements au sein d'un objet.

Pour la SPL, j'ai jeté un oeil sur php.net, mais je t'avoue ne pas voir en quoi elle m'aiderait.

Pour le fait d'être limité à une seule fonction, si j'ai bien compris ce que tu voulais dire, et bien non. Pour chaque évènement, tu peux placer autant de hooks que tu le souhaites (hook ici = fonction à appeler). D'ailleurs j'ai une petite idée d'amélioration à ce sujet que je vais implémenter dans la prochaine version.

Pour les exceptions, tu as raison, je vais faire une mise à jour tout de suite.

D'autres remarques/suggestions ?

Ca a l'air sympa. Bon personnellement je trouve complètement inutil de réécrire une Nième classe pour mysql s'il n'y a rien d'innovant/différent par rapport aux autres, mais ce n'est pas le sujet.

Concernant ta clase, y'a juste un truc qui me saute aux yeux (je n'ai pas lu en profondeur mais ça pique ^^) c'est ta fonction make_attributes(). Tu utilises la fonction count() dans ta boucle. Ca veux dire qu'à chaque boucle, elle sera appelée à nouveau pour le même résultat. Stock plutot une bonne fois le résultat dans une variable, ça améliorera les perfs de ta méthode. Ah tant qu'à faire, vérifie que le tableau n'est pas vide avant de l'utiliser.

Autre chose, ne fais pas un die() si une requête ne passe pas, utilise les exceptions ;)

++

Ah j'ai oublié de le dire dans le commentaire : j'ai ajouté un petit fichier d'exemple d'utilisation.

Pas une blacklist (qui ne permet pas de "comprendre" le comportement d'un robot), une base de données qui contient juste des statistiques. Si une même adresse ip envoie un contenu sensiblement identique sur plusieurs sites, et pire encore si c'est fait dans un interval très court, des mesures sont prises (temps d'attente plus long pour cette ip, ban, mail de prévention des admins concernés, etc.).