voila, je vous souligner que la methode DELETE de mysql n'est pas recommandée.
De manière générale, il est plus prudent d'avoir un 'flag' delete (0 = effacé, 1 = normal), plutot que de faire un "DELETE".
Pourquoi ?
Tout simplement que si un moteur de recherche passe sur votre page, et que par malheur, vous avec mal géré la chose, le moteur de recherche suit tout les liens, et par conséquent, il va suivre les liens qui efface des données dans la base.
Et si c'est vraiment mal géré, apres le passage du moteur de recherche, vous pouvez avoir des tables un peu vide.
Par conséquent, utiliser des 'flag' delete dans vos tables, et prévoyer des script a part, executable que manuellement, et qui vous nettoient ces tables la.
a priori non pcke si tu mets un petit test d'existence de variable de session au début de ta page, je doute que les bot ils arrivent a se connecter tout seuls lol
oui, si tu geres tout correctement.
Mais comme personne n'est a l'abris d'une erreur...
ou d'une défaillance technique qui laisserais passer les bots, c'est quand meme plus sur d'utiliser cette pratique (utilisée dans le milieu professionel, en général)
Moi je dis ca, c'est pour éviter à des personne de se trouver dans un cas ou ils auraient des tables vides ^^
Je ne suis pas vraiment d'accord avec toi, car sur un site pas mal utilisé c'est un coup a voir une table qui grossis assez vite sans que l'on sache pouquoi !
Je suis plus adepte d'une demande de confirmation via formulaire javascript et autre !
Ensuite, dans le cas par exmples d'une messagerie, il faudrait un bouton pour l'admin qui vide tout les messages cencé etre delete ... c'est un peu compliqué pour pas grand chose !
de tout facon si le script est mal fait il y aura moyen de faire chier le monde
Bon, donc la vous partez du principe que vos script sont parfait, et exempt de toute erreur...
Est-ce vraiment mieux ?
De plus, sans compté les robots, puisque vous ne pensez pas cet argument valable (soit dit en passant, l'erreur est humaine ), prenons un autre exemple.
Vous venez de terminer votre, site et il marche bien, y a plein de monde dessus. Parfais.
Mais les failles, ca existe, la preuve, meme le site PHP-nuke (ou je sais plus lequel, lol), s'est fait piraté.
Sans allé jusque la, vous avez une petite faille qui permette a un membre d'effectuer des actions en boucle.
Si c'est une insertion, ok, ca peut tuer la base, mais en fesant un petit delete des champs, ca repart nickel ^^.
Si c'est un delete, et que vous effacer les lignes, vous les retrouvez ou ces lignes ???
Si vous étes prevoyant, vous avez une sauvegarde de votre table tout les jours.
Mais sinon... Dommage ^^
De plus, meme avec une sauvegarde, si c'est un site important, avec des commandes, ou ce genre de chose, perdre ne serait ce que les 50 commande passée dans la journée, ca fait mal, car les personnes ont déja payée, et impossible de savoir qui...
Donc je pense que vous devriez quand meme médité un peu plus, et me proposer des arguments plus valable qu'un "oui, mais si c'est bien géré, pas de probleme.", ou "ca prend trop de donnée pour rien".
Un flag 0 ou 1, ca prend un octet !!! (tinyint de 1). Soit 100Ko pour 100 000 entrées dans la table. Vous pensez que ca va tuer votre base ???
Maintenant si ya une page qui met les flags a 0 /1
ba ca le fera quand meme
Et si tu t'en rend pas compte quand tu veux faire le menage dans les tables ba tu supprimes ce que "google" a mis a 1.
Donc ca systeme est bien pour garder en memoire toutes les commandes passé par example mais ca ne ressoud pas le probleme posé.
La seule solution que je voix c tjs de prevoir un bouton de confirmation quand tu veux delete un truc (bouton de formulaire)
bref de bien coder ses trucs.
sauf qu'en general, si un utilisateur voit qu'il lui manque des données, il le feras savoir, et le webmaster pourras les remettre ^^.
Alors qu'en fesant un delete simple, y a aucun moyen de revenir en arriere.
Et meme dans un cas d'intention mauvaise, un simple bouton de confirmation se détourne ^^
Ouais et apres, dans tes requete select, tu est obliger de rajouté un parametre a WHERE, il faut que FLAG = 1... Ca ca va pas faire ralentir les grosse requete ?