Discussion :

[Invité]

Bonjour,

Je suis débutant en Base de Données, n'ayant pas trouvé forum plus approprié, je me permet de poster ici. Si je suis au mauvais endroit (ce que je n'espère), un bienveillant modérateur pourra déplacer le sujet en bonne place ? Je vous remercie.


J'ai une interrogation à laquelle je ne parviens pas à trouver réponse.

J'ai une table "Formulaire" contenant comme propriétés "Date_limite" et "Statut".
Supposons que le statut actuel soit "Valide".
Supposons que la date limite soit le 15/05/2016.
Nous somme aujourd'hui le 16/05/2016.

Est-ce possible via le sgbd de mettre à jour le champ "Statut" pour que celui-ci passe de la valeur "Valide" vers la valeur "Invalide" ? C'est à dire, une espèce de script ou je ne sais, interne au sgbd, qui se chargerait tout les jours de mettre automatiquement à jour le champ "Statut" en fonction de la date limite par rapport à la date actuel ?

C'est une question d'ordre générale, pas forcément lié à un sgbd en particulier.

Je vous remercie de votre attention et de vos futures réponses,

isNaN.

[al1_24]

Pourquoi pas tout simplement une vue ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SELECT  frm.*
    ,   CASE WHEN frm.date_limite > CURRENT_DATE
            THEN 'Valide' ELSE 'Invalide' END AS statut
FROM    formulaire  AS frm
;

[escartefigue]

Attention toutefois :
si le traitement doit pouvoir être utilisé en mode reprise, il ne faut pas utiliser la current_date, mais une date en paramètre
Même remarque s'il s'agit d'un traitement batch de nuit qui peut démarrer avant minuit et se terminer le lendemain.

[SQLpro]

Effectivement la solution de Al_24 est la meilleure.

Par principe les applications ne devraient JAMAIS attaquer directement des tables, mais toujours passer par des vues. Il y a de nombreuses raisons à cela, la première étant la facilité de restructuration de la base du fait de la couche vue qui rend indépendant le lien entre les données et les applications.

La possibilité de présenter l'information à moindre coût en est une autre.

En effet il serit possible de planifier une tâche qui mettrait à jour régulièrement ces données, par exemple quotidiennement à 0h. Mais cette tâche devrait donc s'exécuter même s'il n'y a rien à faire et même si personne ne consulte les données !
Le surcoût d'un vue étant plus que modeste en comparaison d'un processus mis en attente dans un planificateur !

A +

[StringBuilder]

Je profite de cette intervention de Frédéric pour l'illuster avec ce billet que j'ai écrit en septembre, montant le grand avantage de passer par des vues afin d'avoir plus de souplesse dans l'évolution du modèle des données (qui n'est rarement bon du premier coup quand il s'agit d'un projet donc le cahier des charges évolue dans le temps).

http://sgbd.developpez.com/actu/9019...StringBuilder/

[DotNetMatt]

Très intéressant ! Sur un projet en cours avec SQL Server, je n'ai pas la chance d'avoir un DBA dans mon équipe. J'ai tendance à utiliser des procédures stockées (SP), et peu de vues. Peut-on considérer qu'elles (SP) apportent la même souplesse que les vues comme suggéré ici ? Est-ce également une bonne pratique que de "brancher" les SP sur des vues ?

[StringBuilder]

Les SP jouent en effet le même rôle.

Cependant, l'avantage des vues, c'est qu'on fige moins le code : avec une SP, on va devoir choisir exactement quels éléments sont filtrés, quels éléments sont retournés, etc. Avec une vue, on permet "qui peut le plus peut le moins".

Habituellement, d'un point de vue purement maintenabilité du code, je branche toujours mes SP sur des vues (sauf quand ce sont des SP à sécurité forte, telles qu'une validation de login par exemple).

D'un point de vues performances, je ne suis cependant pas certain que brancher des SP sur des vues plutôt que des tables soit très heureux. Cependant, du moment que les deux sont bien écrites, c'est toujours mieux qu'une requête écrite pas un générateur de code

[SQLpro]

Très intéressant ! Sur un projet en cours avec SQL Server, je n'ai pas la chance d'avoir un DBA dans mon équipe. J'ai tendance à utiliser des procédures stockées (SP), et peu de vues. Peut-on considérer qu'elles (SP) apportent la même souplesse que les vues comme suggéré ici ? Est-ce également une bonne pratique que de "brancher" les SP sur des vues ?

Non, pas du tout !

une vue peut être interrogée par SELECT (donc jointure,; filtrage...), une procédure non
Une vue peut être mise à jour donc modifier les données des tables. Une procédure non...

A +