none
Sincronizzare tabelle interscambio RRS feed

  • Domanda

  • Salve, scusate la domanda vaga, ma non ho idea di come approcciare questo problema, chiedo quindi consigli e spunti:

    Ho delle viste che filtrano dei dati che dovrebbero essere visualizzati poi su Azure tramite un database di interscambio che preleva i dati tramite Azure DataFactoring.

    Il problema è che non posso utilizzare, come sorgente, le viste in quanto non indicizzabili...

    Devo per forza utilizzare delle tabelle... volevo quindi creare, partendo dalle viste, delle tabelle che però devono essere "sincronizzate"... riallineate quindi per insert, update e delete dei record nelle tabelle sottostanti...

    Quale strada dovrei preferire?...

    avrei pensato di ricreare sistematicamente le tabelle partendo dalle viste ma così mi perderei la cancellazione dei record perché sempre la tabella da zero....

    Grazie anticipate



    Marco

    venerdì 21 giugno 2019 09:05

Risposte

  • Il database di partenza è sqlserver, quindi potresti semplicemente creare dei Trigger che aggiornano le tabelle di scambio dati quando variano le tabelle reali.

    Altrimenti, puoi creare una o più stored procedure che cancellano e aggiornano le tabelle di interscambio ed utilizzare l'Agent di SQL Server per eseguire gli script in modo temporizzato. Se usi sqlexpress, che non ha l'agent, potresti farlo fare ad un programma scritto ad hoc oppure puoi prendere ispirazione da questo progetto:

    http://www.sabrinacosolo.com/modificare-i-job-di-minisqlagent-per-poter-gestire-il-timeout/

    e scaricarne il codice che fornisce una mini versione di un agent per SQL Server.

    saluti


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 giugno 2019 10:03
  • Per le cancellazioni, se nella tabella origine non marchi i record come cancellati, il metodo più sicuro che hai è quello di fare un trigger che prima della Delete vada a modificare il flag di cancellazione sulla tua tabella di interscambio.

    se questo non fosse possibile devi fare una SP che fa una join fra la tabella interscambio e la tabella sorgente e quando il record della tabella sorgente non esiste più marca il record come cancellato:

    SELECT
         is.IDInterscambio
        ,is.IDMaster
        ,ms.IDMaster
    FROM
        TabellaInterscambio is
    LEFT OUTER JOIN
        TabellaMaster ms
    WHERE
        is.ISDeleted = 0
    AND
        ms.IDMaster is null

    Questa query ti ritorna tutti i record della tabella interscambio che risultano non cancellati ma che non hanno corrispondenza nella tabella "master" del database, così rilevi i cancellati non ancora marcati come tali sulla tabella di interscambio e ovviamente puoi fare una UPDATE di ISDeleted per tutte in modo che hai evidenziato le righe cancellate, poi vai avanti.


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 giugno 2019 13:07

Tutte le risposte

  • Il database di partenza è sqlserver, quindi potresti semplicemente creare dei Trigger che aggiornano le tabelle di scambio dati quando variano le tabelle reali.

    Altrimenti, puoi creare una o più stored procedure che cancellano e aggiornano le tabelle di interscambio ed utilizzare l'Agent di SQL Server per eseguire gli script in modo temporizzato. Se usi sqlexpress, che non ha l'agent, potresti farlo fare ad un programma scritto ad hoc oppure puoi prendere ispirazione da questo progetto:

    http://www.sabrinacosolo.com/modificare-i-job-di-minisqlagent-per-poter-gestire-il-timeout/

    e scaricarne il codice che fornisce una mini versione di un agent per SQL Server.

    saluti


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 giugno 2019 10:03
  • Pensavo anche io di fare come suggerisci, tuttavia non mi è chiaro come poter gestire eventuali cancellazioni..... 

    nel senso che vorrei mantenere i record ma contrassegnarli come cancellati:

    Tabella sorgente (Risultato di una vista non indicizzabile che accoda i record sulla tabella Sorgente)

    Tabella destinazione (dove accodo se non esiste ma contrassegno "Eliminato" se non più presente sulla tabella Sorgente)


    Marco

    venerdì 21 giugno 2019 12:39
  • Per le cancellazioni, se nella tabella origine non marchi i record come cancellati, il metodo più sicuro che hai è quello di fare un trigger che prima della Delete vada a modificare il flag di cancellazione sulla tua tabella di interscambio.

    se questo non fosse possibile devi fare una SP che fa una join fra la tabella interscambio e la tabella sorgente e quando il record della tabella sorgente non esiste più marca il record come cancellato:

    SELECT
         is.IDInterscambio
        ,is.IDMaster
        ,ms.IDMaster
    FROM
        TabellaInterscambio is
    LEFT OUTER JOIN
        TabellaMaster ms
    WHERE
        is.ISDeleted = 0
    AND
        ms.IDMaster is null

    Questa query ti ritorna tutti i record della tabella interscambio che risultano non cancellati ma che non hanno corrispondenza nella tabella "master" del database, così rilevi i cancellati non ancora marcati come tali sulla tabella di interscambio e ovviamente puoi fare una UPDATE di ISDeleted per tutte in modo che hai evidenziato le righe cancellate, poi vai avanti.


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 giugno 2019 13:07
  • Direi che mi stò chiarendo molto le idee... 

    ora devo capire quale potrebbe essere l'evento scatenante per l'insert perchè non conosco ancora affondo la logica di funzionamento della vista di selezione... ma in linea di principio credo di esserci... ho due potenziali strade, utilizzare dei trigger per lanciare l'insert (devo necessariamente addentrarmi nella logica del gestionale) o eseguo una store più volta al giorno...



    Marco

    venerdì 21 giugno 2019 13:17
  • Se le tabelle che devi leggere non sono tue, se mi trovassi al tuo posto seguirei la strada della stored procedure, perché preferisco non toccare i DB gestiti da altri, per il semplice motivo che potrebbero cambiarne la forma negli aggiornamenti o più semplicemente potrebbero eliminarti i Trigger durante le manutenzioni o peggio ancora i tuoi trigger potrebbero creare problemi all'applicazione di terzi.

    Se invece sei tu che ti occupi del database origine allora i Trigger probabilmente sono la via più semplice.

    quella che chiami vista di selezione, io la metterei direttamente come query nella mia stored procedure (potrebbero essere anche più di una le SP), in modo che sia semplice creare il tutto, verificare, debuggare e poi semplicemente eseguire, e per la manutenzione è tutto più compatto.

    saluti


    Sabrina C. - http://www.dotnetwork.it

    venerdì 21 giugno 2019 14:07
  • E' da escludere a priori l'utilizzo delle code?

    Marco

    lunedì 24 giugno 2019 13:26
  • Non ho mai avuto occasione di usare una coda e quindi non so dirti se sono un buon metodo o meno, però presumo che la coda implichi un programma che accoda e uno che toglie da coda le cose. Non so se si può fare direttamente sul semplice SQL. Prova a cercare documentazione in merito.

    https://www.sqlservercentral.com/articles/working-with-queues-in-sql-server

    In questo articolo viene discusso l'argomento.


    Sabrina C. - http://www.dotnetwork.it

    lunedì 24 giugno 2019 16:51
  • Ho trovato interessante anche : T-SQL MERGE..

    https://docs.microsoft.com/it-it/sql/t-sql/statements/merge-transact-sql?view=sql-server-2017

    ma per ora ho approntato il metodo con delle store procedure.


    Marco

    lunedì 8 luglio 2019 12:59