MYSQL "DELETE" --> Pas bien !!

Répondre
keitarosan
le 17/02/2005 à 12:30
keitarosan
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.

Vala vala ^^
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
bibi
le 17/02/2005 à 13:54
bibi
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
commit suicide
keitarosan
le 17/02/2005 à 14:11
keitarosan
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 ^^
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
moogli
le 17/02/2005 à 14:21
moogli
Salut,

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 smiley


smiley
Il en faut peu pour être heureux !!!!!
keitarosan
le 17/02/2005 à 15:54
keitarosan
moi je disais ca parce que c'est une méthode utilisée professionnellement (du moins dans les boites que j'ai vu).
Donc c'est que ca a son utilité.

De plus, le javascript, c'est pas recommander pour etre secure, car nécessairement visible dans le code...
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
Bzh
le 18/02/2005 à 00:50
Bzh
Oui mais les moteurs de recherches y connaissent pas ça le javascript... Moogli à raison !!!

Et puis de là, laisser les moteurs des recherches accèder aux scripts de gestion de la base de données...

Je verrai bien Google poster un message dans le forum de lephpfacile... Non ???? smiley

smiley
keitarosan
le 18/02/2005 à 12:34
keitarosan
Bon, donc la vous partez du principe que vos script sont parfait, et exempt de toute erreur...

Est-ce vraiment mieux ? smiley

De plus, sans compté les robots, puisque vous ne pensez pas cet argument valable (soit dit en passant, l'erreur est humaine smiley), 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 smiley ^^
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 ???


KeitaroSan
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
Cart
le 18/02/2005 à 13:04
Cart
Meditons:
Partons du principe que c mal géré :

si une page avec delete ca delete tes champs

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.

Voila :)
Répondre
LoadingChargement en cours