Discussion :

[LinuxUser]

Bonjour,
Admettons que j'ai une Table de Fournisseurs et une de Commande (passées auprès des fournisseurs).
Je crée une autre Table HistoriqueCommande qui contiendra les commandes supprimées (de la table commande) une fois la date de livraison atteinte.

Voilà à présent ma question :

Je souaiterais qu'à chaque commande supprimée elle soit archivée dans la Table HistoriqueCommande.//ça je l'ai fait avec un TRIGGER sans problème
Par contre comment gérer automatiquement le fait qu'une date de livraison soit atteinte entraine la suppression de cette commande.
Car avec les TRIGGER on ne peut agir qu'a la suppression,l'insertion,la mise à jour d'une table. On ne peut pas la "surveiller".
Le mien que je puisse faire c'est une procédure, mais il faut tout de même la lancer manuellement.

Donc voilà, si je me suis bien exprimé, savez-vous comment effectuer cette "surveillance" automatiquement?

Merci.

[orafrance]

tu ne peux pas, faut faire un job qui se déclenche tous les jours à minuit éventuellement... Sinon, on peut quand même imaginer que quand la livraison est effectivement faite, la date de livraison est mise à jour et alors tu peux déclencher un trigger.

Par ailleurs, le fonctionnement parait bancal... ça me paraitrait plus logique et performant de mettre une période de validité sur la commande (si date de fin < aujoud'hui alors la commande est terminé) ou un status (OUVERTE, ANNULEE, CLOSE, EN COURS, etc...)

[LinuxUser]

Mais pour déclencher le TRIGGER il faut un DELETE,INSERT ou UPDATE.
C'est bien là le problème, comment "surveiller" la date de livraison pour qu'une fois atteinte on SUPPRIME le tuple et donc déclencher le TRIGGER pour archiver.
Vous voyez ce que je veux dire?

[Invité]

Avec un job, tu t'affranchis du trigger.

[orafrance]

Mais pour déclencher le TRIGGER il faut un DELETE,INSERT ou UPDATE.
C'est bien là le problème, comment "surveiller" la date de livraison pour qu'une fois atteinte on SUPPRIME le tuple et donc déclencher le TRIGGER pour archiver.
Vous voyez ce que je veux dire?

je vois très bien et je t'ai dit que tu pouvais faire un job déclenché tous les jours à minuit

Mais ce que je vois aussi c'est qu'une livraison ça peut être en retard... donc que la date de livraison REELLE doit être renseignée quelque part... ce qui se fera avec un update et tu pourras alors déclencher un trigger.

M'enfin, j'suis pas dans l'appli et tu fais bien comme tu veux

[LinuxUser]

C'est juste, vous aviez raison je me suis trompé.
Je vois ce que j'ai à faire à présent.
Désolé de vous avoir dérangé pour rien.

[Michel SALAIS]

C'est juste, vous aviez raison je me suis trompé.
Je vois ce que j'ai à faire à présent.
Désolé de vous avoir dérangé pour rien.

Il peut être utile de sonder du côté du partitionnement de la table ...

[orafrance]

tu vas un peu vite en besogne... en plus, je rappelle à toute fin utile que l'option est loin d'être gratuite

[Michel SALAIS]

tu vas un peu vite en besogne... en plus, je rappelle à toute fin utile que l'option est loin d'être gratuite

ِCertainement!

C'est néanmoins une option valable à regarder et ça peut valoir le coût. Nous pouvons énumérer plein de points positifs par rapport à la situation décrite ici. D'un autre côté, certains ont déjà la licence mais ne l'utilisent pas

[orafrance]

on peut parler de parallélisme et standby database dans ce cas

Je ne remets pas en cause l'intérêt du partitionnement, juste que dans la discussion présente c'est un peu HS au regard du manque d'info notamment en terme de volume

[Michel SALAIS]

on peut parler de parallélisme et standby database dans ce cas

Je ne remets pas en cause l'intérêt du partitionnement, juste que dans la discussion présente c'est un peu HS au regard du manque d'info notamment en terme de volume

Désolé mais d'abord j'ai dit que c'est une piste à sonder c'est-à-dire une solution éventuelle
Et ça n'a rien à voir avec toutes les technologies que tu as énumérées. C'est directement lié à la question originale dans ce sens : Le partitionnement peut rendre le job proposé à juste titre et éventuellement la deuxième table HistoriqueCommande carrément inutiles puisque l'historisation se fera "naturellement". Bien sûr la taille des données est importante pour en décider mais le paratitionnemnet n'est pas hors sujet comme tu l'a dit. Après tout notre rôle dans le forum est également de conseiller sur la technologie à utiliser non

[orafrance]

J'ai bien compris... mon intervention a surement paru intransigeante alors que ce n'était pas le cas, désolé Fallait lire mon message sur le ton de la légèreté, les smilies en témoignent

Ceci étant dit, le déplacement entre partition à quand même un coût et dans le cas présent je pense que c'est juste le besoin fonctionnel qui est mal défini. On ne supprime pas (logiquement ou physiquement peu importe) une commande de la même manière qu'on ne supprime pas des factures.

[Michel SALAIS]

J'ai bien compris... mon intervention a surement paru intransigeante alors que ce n'était pas le cas, désolé Fallait lire mon message sur le ton de la légèreté, les smilies en témoignent

Non Orafrance! Je ne l'ai pas pris autrement ...
Mais je voulais persister puisqu'il me paraît que nous étions devant une situation typique d'utilisation de partitionnement (indépendamment de la suppression des commandes et du trigger). Des opérations basées sur la date et que nous voulons historiser ...

Ceci étant dit, le déplacement entre partition à quand même un coût et dans le cas présent je pense que c'est juste le besoin fonctionnel qui est mal défini. On ne supprime pas (logiquement ou physiquement peu importe) une commande de la même manière qu'on ne supprime pas des factures.

Je suis entièrement d'accord.

[orafrance]

on est d'accord alors