Bonjour à tous,
 
J'ai modifié mon trigger before delete jusqu'à en plus pouvoir... mais rien n'y fait il refuse de fonctionner correctement.  
 
Grosso modo j'ai une table 'news', une table 'usager' et une table 'historique', quand j'efface une news je souhaite que mon trigger efface automatiquement les lignes correspondant à cette news dans ma table 'historique'.
 

 
J'ai essayé de modifier mon trigger, avec ou sans jointure, mais le résultat est toujours le même.
Message d'erreur:
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TRIGGER deleteNewsHisto BEFORE DELETE ON news FOR EACH ROW BEGIN
DELETE FRO' at line 1
 
Voici les contraintes de mes tables:

 
La dernière version de mon Trigger est celle-ci :

 
Si vous voyez ce qui ne va pas, je vous écoute d'une oreille attentive.
 
Question supplémentaire: si je veux ajouter un delete à ce trigger pour qu'il efface en plus les occurences liées à ma news dans une autre table, est-ce possible? (je veux dire sans écrire un autre trigger mais en ajoutant seulement cette instruction à mon trigger existant).

Les triggers c'est le mal.
Utilise plutot une deuxieme query dans ton application pour faire le nettoyage, ou mieux encore, ne l'efface pas et fais une maintenance qui tourne toutes les x minutes/heures (ca depend de la quantité) pour effacer l'historique orpheline.
 
Avec la maintenance tu acceleres tes delete et tu peux deporter le nettoyage a un moment ou il y a moins d'utilisateurs.

La syntaxe de ton trigger semble correcte, si ce n'est que le delimiteur n'est pas forcément celui que j'aurais choisi.
Essaye de le changer pour voir...
Comment exécutes-tu la requête de création?
 

source?

Et rajouter un simple "ON DELETE CASCADE" sur la forward key, ce ne serait pas plus simple  
(certes, ça n'explique pas le problème )

Mon experience avec sql et une armée de dev (1000+) avec des idées plus originales les unes que les autres.
Le bon sens aussi...
 
Les triggers ajoutent un niveau de traitment pratiquement toujours caché et en general qui ne tiens pas compte de l'impact sur les perfs.
Ce qui est fait dans un trigger peut dans pratiquement tout les cas etre fait en dehors de maniere plus claire, plus souple et plus rapide.
L'utilisation correcte d'un trigger est extremenent rare et cantoné a des cas tres particulier.
 
Les triggers, avec les boucles dans les procedures et toute une serie de choses sont des indications d'un manque de connaissance en developpement DB, d'une mauvais analysise du projet ou d'un mauvais design de la DB...

+1 j'approuve entièrement ce que dit Oliiii, et ça fait plaisir de lire une critique des triggers, parce que c'est une plaie.

Je suis aussi assez d'accord avec le point de vue de Oliiii sur les triggers. Cependant, j'en comprends aussi l'utilité. A la base, c'est toujours une question d'intégrité des données. Si un utilisateur commence à bidouiller les données sans passer par l'appli et que les traitement d'intégrité sont fait par l'appli, la BD va être mise à mal. Alors qu'avec les triggers, non

 
news.OLD.idnews à remplacer par OLD.idnews : le moteur MySQL sait déjà que OLD est un enregistrement de la table news.
 

 
Sur le principe des problèmes de perfs, je suis globalement d'accord. D'ailleurs hier, j'ai tué une base de données MySQL pendant 20 minutes, en faisant un UPDATE d'une seule table qui m'a déclenché une ribambelle de triggers autant de fois qu'il y avait d'enregistrements dans la table, chaque triggers faisant individuellement des SELECT, des INSERT ou des UPDATE.

 
Dans ce cas la c'est le design de la DB qui a un probleme
L'integrite peut etre assurée par la DB si les foreign keys sont utilisées. N'importe quel utilisateur/appli devra ajouter/effacer les enregistrements dans le bon ordre et l'integrité sera toujours correcte. Le role du SGBD c'est de proteger l'integrité des données, pas d'en faciliter les delete
 
Un des rare cas ou les triggers sont difficil a eviter c'est pour de l'audit qui doit etre fait independement de l'appli (audit legal, trouvage de crétin qui delete ce qu'il ne devrai pas, etc ...). Et encore ca depend des SGBD, dans SQL et Oracle il y a des process tout fait qui peuvent faire ca avec un minimum d'impact et de maniere transparente.

je suis aussi d'accord sur les commentaires des triggers ...