MYSQL "DELETE" --> Pas bien !!

page 1 page 2
Répondre
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
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 ^^
bibi
bibi
Déconnecté
commit suicide
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
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
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 ^^
moogli
moogli
Déconnecté
Il en faut peu pour être heureux !!!!!
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
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
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...
Bzh
Bzh
Déconnecté
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
Koboneil
Koboneil
Déconnecté
Koboneil
Bah c'est déjà fait regarde


Ok je sors smiley
Bzh
Bzh
Déconnecté
lol smiley

smiley
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
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
Cart
Cart
Déconnecté
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 :)
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
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 ^^
Cart
Cart
Déconnecté
moi je test que lutilisateur est admin pour faire des deletes donc je n'ai aucun problem :)
bibi
bibi
Déconnecté
commit suicide
  1. 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 ??? 



Sauf que ca ne garde pas QUE ce champ la, ca garde aussi les autres donc pas 1 octet :)
keitarosan
keitarosan
Déconnecté
>> http://projectopensource.free.fr/index.php?m=2&m2=5&s=8 <<
bah un batch prévu tout les x jours, ca supprime bien les entrées quand meme.

Et puis déja, faut les mettres les 100 000 entrées ^^
mobman02
mobman02
Déconnecté
http://damienalexandre.fr/
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 ?
page 1 page 2
Répondre
Accès rapide :

Remonter Remonter
L'éditeur javascript - CSS - Gentoo - Tutoriaux PHP - Tutoriels PHP - Php - Breizh Blog