Bonsoir,

Je m'intéresse beaucoup à ces sujets actuellement et j'aimerai des explications quant à savoir quand doit-on créer des procédures, quand doit-on faire des vues et quand doit-on créer des triggers ?

J'ai souvent dans mes codes des petites fonctions du genre listeCategories($db) qui va retourner la liste des catégories.
De cette façon, j'peux le traiter très simplement sans me pré-occuper de la requête à l'avenir. Est-ce le genre de cas où la procédure stockée est appropriée ?

Pour les triggers, dans quels cas peut-on laisser la base de donnée se charger de faire des modifications ?
Par exemple, prenons une boite de messagerie interne à un site comme celle présente sur le site du zéro.
Puis l'un des participants supprime la conversation de sa boite.
Est ce l'application ou un trigger qui doit supprimer complètement la conversation de la base de donnée lorsque le dernier participant supprime la conversation ?

Bonjour,

D'après ce que je sais (je n'ai fait que la théorie de la chose), un déclencheur permet d'effectuer une opération (procédure) sur ta base AUTOMATIQUEMENT, à chaque fois qu'une condition est rencontrée. Par exemple tu veux faire un update de telle table si tu y insères des données, ou alors tu veux faire une modification à chaque début de mois.

Citation : wikipedia

Dans les bases de données, lors de la mise à jour ou de la suppression d'une donnée, si un déclencheur existe, il peut lancer automatiquement une procédure stockée, qui agit en parallèle sur la même donnée dans une table afférente. Cela permet d'automatiser certains traitements assurant la cohérence et l'intégrité de la base de données.
Trigger déclenché lors d’une insertion ou d’une modification de la table table_example en SQL :

CREATE OR REPLACE TRIGGER trigg_example
 BEFORE INSERT OR UPDATE ON table_example
 FOR EACH ROW
 WHEN (NEW.no_line > 0)
 DECLARE
     evol_exemple NUMBER;
 BEGIN
     evol_exemple := :NEW.exemple  - :old.exemple;
     DBMS_OUTPUT.PUT_LINE('  evolution : ' || evol_exemple);
 END;

Une procédure stockée est un ensemble d'instructions SQL pré-compilées, stockées dans une base de données et exécutées sur demande par le SGBD qui manipule la base de données.
Les procédures stockées peuvent être lancées par un utilisateur, un administrateur DBA ou encore de façon automatique par un événement déclencheur.

Citation : Zazou

Est ce l'application ou un trigger qui doit supprimer complètement la conversation de la base de donnée lorsque le dernier participant supprime la conversation ?

Selon moi c'est l'application, mais tu peux utiliser un déclencheur pour effectuer cette action que tard dans la soirée, quand peu de gens sont sur le site, histoire de pas encombrer le serveur.

Pour ce qui est des vues, j'en sais un peu plus .
Il existe (au moins) deux sortes de vues.
Les vues "classiques" permettent de faire une "capture" de ta base de données ou d'une partie de ta base à un moment donné. C'est comme une requête classique qui va te permettre de créer une table vituelle.
Les avantages :
- sécurité. Les personnes voulant telles informations dans ta base ne connaissent pas tes tables ni la structure mais peuvent accéder à ce qu'ils veulent en affichant / interrogeant des vues. Les vues sont mises à jour à chaque fois qu'elles sont appelées.
- rapidité d'écriture, clareté. Si tu utilises des sous requêtes ou des parties de requêtes toujours les mêmes, tu peux les transformer en vues pour les appeler (grâce à leur nom) à chaque fois que tu en as besoin dans d'autres requêtes.
- si tu changes quelque chose à la structure de la base de données, il te suffit de changer la structure de ta vue pour qu'elle reste correcte.
Inconvénent : la requête est exécutée à chaque fois que la vue est appelée.

Il existe aussi les vues matérialisées, plutôt utilisées pour les entrepôts de données. Elles se font uniquement avec des select.
Contrairement à une vue classique, cette vue est réellement stockée sur le disque, comme une réelle table. Tes données sont donc dupliquées.
Ce genre de vues se fait donc sur des données peu / pas susceptible d'être mises à jour.
Tu peux donc l'indexer par exemple (pour des recherches plus efficaces)
Le gros avantage est que la requête liée à la vue n'est exécutée que lors de la création de la vue, ensuite lorsque tu veux utiliser cette vue tu ne fais que la consulter, pas besoin de relancer la requête.


En espérant avoir été clair ,

Romain

Citation

Pour les triggers, dans quels cas peut-on laisser la base de donnée se charger de faire des modifications ?

C'est assez vague, mais en gros :

- si la modification en question est nécessaire pour garantir l'intégrité des données (intégrité référentielle, etc) alors elle doit être faite par la BDD (dans un trigger par exemple). C'est pourquoi c'est la BDD qui gère les foreign keys et non l'application.

Dans ton exemple de messagerie, ça dépend de ce que tu définis comme correct. Si tu décides que ta BDD ne peut pas contenir de conversation sans "propriétaire", alors quand les deux types l'ont supprimée de leur boîte, elle doit être supprimée de la base illico, donc par un trigger.

Si tu décides que la BDD peut contenir des conversations sans "propriétaire", alors tu peux choisir de ne pas les supprimer immédiatement, mais peut-être dans un script cron ou autre, ou de les archiver, etc.

Tu vois c'est assez philosophique XDDDDD

- si la modification doit être immédiate => trigger
- si la modification doit être réalisée quelle que soit l'appli qui modifie la base (site web, cron, etc) => trigger

> J'ai souvent dans mes codes des petites fonctions du genre listeCategories($db) qui va
> retourner la liste des catégories.

C'est pas la peine de faire une procédure stockée pour ça, sauf dans le cas d'un DBA parano qui ne donne aucun droit sur aucune table, et seulement le droit d'exécuter des procédures stockées. Dans ce cas ton appli ne contient pas de SQL, seulement des appels à des procédures stockées qui sont donc un genre d'API. Pas très pratique cependant...

Tu peux mettre une procédure stockée pour un code qui va être en commun entre plusieurs applis ou scripts (comme ça tu ne l'écris qu'une fois), ou pour un code qui va effectuer beaucoup de requêtes, pour que ça aille plus vite, etc. Pour un petit select, c'est inutile.

Je plussoie LCN :

- trigger => intégrité de la base de données
- ps => requête récurrente car ps = performance (la requête est précompilée, comme quand tu fais un "prepare" avec PDO)
- vue => opération multi-application exceptionnelle. Les vues ont des performances exécrables, leur seul intérêt réside dans leur simplicité d'appel.