Discussion :

[Tanebisse]

Bonjour,
On dit toujours qu'il faut gérer les règles métier sur la couche métier. Mais peut-on quand même utiliser la puissance des BDD pour gérer la suppression en cascade grâce à "ON DELETE CASCADE".
Exemple : quand je supprime une instance d'un objet voiture je supprime aussi ses 4 roues.
Merci d'argumenter avec des références.
Est-ce une bonne ou une mauvaise pratique ? Pourquoi ?

Cordialement.

[SQLpro]

Bonjour,
On dit toujours qu'il faut gérer les règles métier sur la couche métier. Mais peut-on quand même utiliser la puissance des BDD pour gérer la suppression en cascade grâce à "ON DELETE CASCADE".
Exemple : quand je supprime une instance d'un objet voiture je supprime aussi ses 4 roues.
Merci d'argumenter avec des références.
Est-ce une bonne ou une mauvaise pratique ? Pourquoi ?

Cordialement.

Généralement NON, particulièrement oui.

Par exemple si les filles sont systématiquement liées, en lien immuable et en petit nombre => OUI,
si les filles peuvent être déplacées des références et en grand nombre non.

Mais il existe d'autres techniques comme SET DEFAULT ou SET NULL qui permettent d'arriver au même résultat via des traitements déportés en batch à condition d'utiliser des vues.

A +

[Tanebisse]

Je n'ai pas bien compris ta réponse "si les filles peuvent être déplacées des références " ni la technique de "SET DEFAULT ou SET NULL".
La vraie question que je pose c'est faut-il systématiquement gérer ça en JAVA ou autres (couche métier) ou peut-on utiliser des DELETE CASCADE. Pourquoi c'est bien ou pourquoi c'est mal ?

[SQLpro]

Je n'ai pas bien compris ta réponse "si les filles peuvent être déplacées des références " ni la technique de "SET DEFAULT ou SET NULL".
La vraie question que je pose c'est faut-il systématiquement gérer ça en JAVA ou autres (couche métier) ou peut-on utiliser des DELETE CASCADE. Pourquoi c'est bien ou pourquoi c'est mal ?

Aucune couche de programmation ne peut simuler l'équivalent des contraintes de bases de données à l'exception des contraintes de domaines.
Il est impossible à un programme JAVA ou C d'effectuer ce travail de fait de deux problématique :

• le fonctionnement naturellement ensemblistes des SGBDR
• la problématique de gestion des accès simultanés concurrentiels.

Donc, non, vous n'obtiendrez jamais d'équivalent en JAVA à ce que fait nativement un SGBDR !

A +

[Tanebisse]

Il est impossible à un programme JAVA ou C d'effectuer ce travail de fait de deux problématique :

En java je fais 2 actions

1. je supprime les roues
2. je supprime la voiture

le problème c'est que si je dois gérer en plus la suppression des pneus et des enjoliveurs, ça fait beaucoup de code pour pas grand chose alors qu'avec un DELETE CASCADE c'est beaucoup plus simple.
J'ai du me tromper de catégorie pour ma question car c'est plus une question de développeur que de DBA.
Mais merci pour les tuyaux.

[Tanebisse]

Merci StringBuilder pour tes précisions.

[SQLpro]

En java je fais 2 actions

1. je supprime les roues
2. je supprime la voiture

le problème c'est que si je dois gérer en plus la suppression des pneus et des enjoliveurs, ça fait beaucoup de code pour pas grand chose alors qu'avec un DELETE CASCADE c'est beaucoup plus simple.
J'ai du me tromper de catégorie pour ma question car c'est plus une question de développeur que de DBA.
Mais merci pour les tuyaux.

Et si votre code Java tombe en panne au milieu vous faites quoi ?????

A +

[Tanebisse]

Mais il existe d'autres techniques comme SET DEFAULT ou SET NULL qui permettent d'arriver au même résultat via des traitements déportés en batch à condition d'utiliser des vues.

OK j'ai vu pour SET DEFAULT ou SET NULL par contre pourquoi des batchs ou traitement déportés ?

[SQLpro]

OK j'ai vu pour SET DEFAULT ou SET NULL par contre pourquoi des batchs ou traitement déportés ?

SET DEFAULT et SET NULL vont présenter de fausses informations puisqu'un client par défaut (par exemple Âne Onyme) comme un client NULL c'est pas terrible pour une facture !

Dans ce cas on présente aux applications des vues qui éliminent les fausses lignes (effacement logique).

La nuit, aux heures creuses, on lance les bach de traitement de purge effective qui vont supprimer les "fausses" ligne par lot de 500 par exemple.

A +

[StringBuilder]

Pour faire simple, si un DELETE CASCADE a pour effet de supprimer quelques dizaines de lignes dans une poignée de tables, l'impact sur le moteur de base de données sera relativement faible.
En revanche, s'il porte sur des millions de lignes dans des centaines de tables, là, pour faire tenir tout ça dans une transaction, ça va poser des locks un peu partout, avec le risque de deadlocks (être bloqué par une autre transaction qui elle-même est bloquée par la nôtre) et risque d'effrondrer les performances du SGBD, voir même de le bloquer.

En alternative aux valeurs "virtuelles" que propose SQL Pro, vous pouvez, depuis votre application cliente, gérer la suppression de toutes les filles connues au moment de la suppression, avant de terminer par un DELETE CASCADE pour shooter les quelques lignes qui auraient pu passer entre les mailles (en raison des traitements concurrents).

Sinon, en plus simple, vous pouvez apposer un flag sur vos tables, que vous pourrez propager par trigger au besoin : ces lignes seront écartées des traitements applicatifs, et vous aurez tout le loisir de les supprimer par lot, sans risque d'accès concurrent, à un moment plus calme.