Je cherche dans mon modèle de données à maintenir des tables de
dénormalisation par des triggers.
Je cherche dans mon modèle de données à maintenir des tables de
dénormalisation par des triggers.
Je cherche dans mon modèle de données à maintenir des tables de
dénormalisation par des triggers.
>
Tu peux songer aux triggers, mais selon ton volume tu auras des impacts de
performance. Pour éviter la mise à jour directe, il te suffit de ne laisser
aucun privilège sur les tables.
Pourquoi ne pas songer à créer plutôt des vues indexées ?
>
Tu peux songer aux triggers, mais selon ton volume tu auras des impacts de
performance. Pour éviter la mise à jour directe, il te suffit de ne laisser
aucun privilège sur les tables.
Pourquoi ne pas songer à créer plutôt des vues indexées ?
>
Tu peux songer aux triggers, mais selon ton volume tu auras des impacts de
performance. Pour éviter la mise à jour directe, il te suffit de ne laisser
aucun privilège sur les tables.
Pourquoi ne pas songer à créer plutôt des vues indexées ?
Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Jean-Nicolas BERGER a écrit:Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
Jean-Nicolas BERGER a écrit:
Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
Jean-Nicolas BERGER a écrit:Les autres solutions ont été envisagées, mais les triggers semblent la seule
solution possible.
Les vues indexées ont été écartées car il y a des jointures réflexives, des
fonctions de type ROW_NUMBER() et des CTE.
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
>
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
>
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
>
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
Bonjour,
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
- Une expression de table commune.
- La clause OVER, qui inclut des fonctions de classement ou d'agrégation de
fenêtre.
- Des jointures externes ou réflexives.
Et comme fonctionnellement, je n'ai pas le choix...
Par contre, le chainage des droits ne semble pas être mon allié sur ce
coup-là. Le but est de me prémunir des développeurs qui mettraient dans le
code de leurs procédures stockées une instruction DML sur les tables
dénormalisées; Par contre, ces mêmes développeurs, dans les mêmes procédures
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
concevoir une chaîne fiable...
Merci.
JN.
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
Bonjour,
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
- Une expression de table commune.
- La clause OVER, qui inclut des fonctions de classement ou d'agrégation de
fenêtre.
- Des jointures externes ou réflexives.
Et comme fonctionnellement, je n'ai pas le choix...
Par contre, le chainage des droits ne semble pas être mon allié sur ce
coup-là. Le but est de me prémunir des développeurs qui mettraient dans le
code de leurs procédures stockées une instruction DML sur les tables
dénormalisées; Par contre, ces mêmes développeurs, dans les mêmes procédures
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
concevoir une chaîne fiable...
Merci.
JN.
Je ne vois pas vraiment ce que ça change. La vue indexée matérialise ses
données, tout comme une table alimentée par un trigger.
En ce qui concerne la sécurité des triggers, si les deux tables
appartiennent au même user (donc sont dans le même schéma, ou dans des
schémas qui ont le même propriétaire), le chaînage de propriété s'applique.
Donc tu n'as pas à faire d'EXECUTE AS. Le trigger aura des privilèges
d'insertion dans ta table dénormalisée même si le contexte d'exécution de
l'INSERT sur la table normalisée ne le permet pas.
Bonjour,
La création d'une vue indexée implique (voir BOL) que la vue ne doit pas
contenir, entre autres :
- Une expression de table commune.
- La clause OVER, qui inclut des fonctions de classement ou d'agrégation de
fenêtre.
- Des jointures externes ou réflexives.
Et comme fonctionnellement, je n'ai pas le choix...
Par contre, le chainage des droits ne semble pas être mon allié sur ce
coup-là. Le but est de me prémunir des développeurs qui mettraient dans le
code de leurs procédures stockées une instruction DML sur les tables
dénormalisées; Par contre, ces mêmes développeurs, dans les mêmes procédures
stockées, pourraient tout à fait modifier des tables de base. Comment
voyez-vous le chainage et les propriétaires des procédures, des tables de
base et des tables dénormalisées? Je doit avouer que je n'arrive pas à
concevoir une chaîne fiable...
Merci.
JN.
>
Oui, mais rien n'empêche de réaliser une première vue indexée avec ses
limitations là sur laquelle les calculs CTE et les fonctions de fenêtrage
vont se porter...
>
Oui, mais rien n'empêche de réaliser une première vue indexée avec ses
limitations là sur laquelle les calculs CTE et les fonctions de fenêtrage
vont se porter...
>
Oui, mais rien n'empêche de réaliser une première vue indexée avec ses
limitations là sur laquelle les calculs CTE et les fonctions de fenêtrage
vont se porter...