Potenzialità trigger e stored procedure

martedì 24 agosto 2010 - 10.27

Samb1985 Profilo | Junior Member

Volevo chiedere informazioni riguardo alle potenzialità di trigger e stored procedure su Slq server 2005 Standard Edition

E' possibile tramite questi strumenti implementare un qualcosa di simile:

1 - Quando si aggiunge un record su una tabella (formato da un solo campo chhar(255)) deve partire una procedura che fa il parsing del campo inserito e lo divide in una serie di sottocampi predefiniti che dovranno esssere scritti su un altra tabella dello stesso db

2 - Quando si aggiunge o modifica un record di una tabella deve partire una procedura che deve lanciare una chiamata http con il metodo get con alcuni parametri che indicano il percorso di files necessari alla chiamata http

Si può fare tutto con trigger e stored procedure o è necessario che siano richiamati applicativi ad hoc esterni ?
--------------------------------------------------------------------------------------

Ogni popolo ha il governo che si merita...

lbenaglia Profilo | Guru

>1 - Quando si aggiunge un record su una tabella (formato da un
>solo campo chhar(255)) deve partire una procedura che fa il parsing
>del campo inserito e lo divide in una serie di sottocampi predefiniti
>che dovranno esssere scritti su un altra tabella dello stesso
>db
Brutto ma possibile con un trigger di INSERT/UPDATE

>2 - Quando si aggiunge o modifica un record di una tabella deve
>partire una procedura che deve lanciare una chiamata http con
>il metodo get con alcuni parametri che indicano il percorso di
>files necessari alla chiamata http
Molto più brutto del precedente forse perseguibile con un trigger CLR.

>Si può fare tutto con trigger e stored procedure o è necessario
>che siano richiamati applicativi ad hoc esterni ?
Sarebbe auspicabile fare entrambe le cose con applicativi esterni.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/

Samb1985 Profilo | Junior Member


>Brutto ma possibile con un trigger di INSERT/UPDATE

In che senso insert/update ? dovrei fare un trigger su insert che poi recupera i primi n caratteri, i secondi n caratteri, ecc e lancia una update con questi valori .... (ci sono le istruzioni t-sql per fare il parsing ?)

>Molto più brutto del precedente forse perseguibile con un trigger
>CLR.
>Sarebbe auspicabile fare entrambe le cose con applicativi esterni.

Il problema è che vista la complessità dei sistemi vorrei evitare di dover definire ulteriori applicativi esterni e lasciare la gestione di questi aggiornamenti ai due db sql server che sono su macchine diverse.


--------------------------------------------------------------------------------------

Ogni popolo ha il governo che si merita...

lbenaglia Profilo | Guru

>In che senso insert/update ? dovrei fare un trigger su insert
>che poi recupera i primi n caratteri, i secondi n caratteri,
>ecc e lancia una update con questi valori .... (ci sono le istruzioni
>t-sql per fare il parsing ?)
No, un after trigger che scatti ad ogni comando di INSERT o di UPDATE.

>Il problema è che vista la complessità dei sistemi vorrei evitare
>di dover definire ulteriori applicativi esterni e lasciare la
>gestione di questi aggiornamenti ai due db sql server che sono
>su macchine diverse.
Credimi, ti stai dirigendo in un ginepraio di problemi sia di realizzazione che di performance.
Un consiglio? Modifica le applicazioni client in modo che utilizzino correttamente il DBMS.
Parsing o chiamate HTTP non sono certo la strada giusta...

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/

Samb1985 Profilo | Junior Member


>No, un after trigger che scatti ad ogni comando di INSERT o di
>UPDATE.
>

>Credimi, ti stai dirigendo in un ginepraio di problemi sia di
>realizzazione che di performance.
>Un consiglio? Modifica le applicazioni client in modo che utilizzino
>correttamente il DBMS.
>Parsing o chiamate HTTP non sono certo la strada giusta...

Il problema è che le applicazioni client sono proprietari e di terze parti non comunicano tra di loro...è necessaria un integrazione in qualche modo...
--------------------------------------------------------------------------------------

Ogni popolo ha il governo che si merita...

lbenaglia Profilo | Guru

>Il problema è che le applicazioni client sono proprietari e di
>terze parti non comunicano tra di loro...è necessaria un integrazione
>in qualche modo...
Il modo che proponi non è quello ideale IMHO.
I DBMS devono rimanere "snelli" per operare correttamente e con ottime prestazioni, ovvero le eventuali regole di business implementate in procedure e/o triggers devono operare esclusivamente sui dati mediante operazioni basate su set di dati (niente parsing, cursori, o in generale elaborazioni a livello di riga).
Tutto il resto deve essere implementato esternamente.

In bocca al lupo.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/

Samb1985 Profilo | Junior Member

Dato che i due applicativi da interfacciare sono proprietari ed ognuno con la propria istanza di db, l'unico modo che ho per intercettare se è stato fatto un INSERT o un UPDATE su una delle due istanze è il trigger giusto ?

Una volta intercettato l'evento devo eseguire la relativa computazione, e questo potrei farlo con un Trigger CLR (definendo opportune classi C# e compilandole in dll che poi dovranno essere aggiunte con CREATE ASSEMBLY sull'istanza SQL SERVER). Il tutto non ho idea con quali performance...

So che l'ideale sarebbe stato che i due applicativi scrivessero direttamente su entrambe le istanze di db...


--------------------------------------------------------------------------------------

Ogni popolo ha il governo che si merita...
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2025
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5