attivatore sqlite o evento applicativo?

0

Ho due code di eventi (code mappate alla tabella) basate su due diversi stati degli stessi dati memorizzati in due tabelle diverse. Gli eventi sono generati su create / update / delete su entrambe le tabelle.

Vincola è che entrambe le tabelle devono essere sincronizzate. Il creare / aggiornare / eliminare in una tabella deve essere riflesso in un'altra tabella.

Quindi la domanda è: dovrei usare il trigger per mettere in coda gli eventi nella tabella o nell'applicazione / oggetto per mettere in coda gli eventi nella tabella? e perché?

Nota:

  1. L'aggiornamento su entrambi è in grado di generare 3 diversi tipi di eventi. Quindi sul livello dell'applicazione sarebbe necessaria una logica differenziale aggiuntiva per generare l'evento corretto.
  2. La cosa negativa nel trigger è che introdurrà eventi duplicati da entrambi i lati. Ad esempio, se alcuni eventi vengono elaborati su una tabella, verrà creato un evento per l'elaborazione su un'altra tabella.
posta bikram990 21.02.2014 - 20:20
fonte

1 risposta

3

Ho scritto questa roba molto tempo fa per un'applicazione C ++ e ho fatto un post sul mio blog. Ecco un breve riassunto (dal momento che the l'articolo originale è piuttosto lungo e contiene allegati di file):

In SQLite scrivi callback in C ++ non elaborato:

File di intestazione (file.h)

#include <iostream>
#include <sqlite3.h>
#include <cstdlib>
#include <assert.h>

void memberfunction(const unsigned char* text1, 
                    const unsigned char* text2, 
                    const unsigned char* text3);
void mcallback(sqlite3_context* context, int argc, sqlite3_value** argv);

Definisce le due funzioni aggiuntive di cui avremo bisogno per il prossimo passo (in realtà la nostra funzione C ++ e una stored procedure SQLite).

File di implementazione (file.cpp)

Questa funzione verrà chiamata dal nostro trigger dal DB.

void memeberfunction(const unsigned char* text1, 
                     const unsigned char* text2, 
                     const unsigned char* text3)
{
    cout << "inserted: " << text1 << "  " << text2 << "  " << text3 << "n";
}

E ora una procedura memorizzata SQLite per chiamare la nostra funzione; un trigger SQLite invocherà questo.

void mcallback(sqlite3_context* context, int argc, sqlite3_value** argv)
{
    assert(argc == 3);
    //SQLite types must be converted to C++ types
    const unsigned char* text1 = sqlite3_value_text(argv[0]);
    const unsigned char* text2 = sqlite3_value_text(argv[1]);
    const unsigned char* text3 = sqlite3_value_text(argv[2]);
    memeberfunction( text1, text2, text3);
}

Non dobbiamo limitare la funzione a una semplice stampa; questa funzione potrebbe avere (per esempio) i dati spostati su un'altra tabella.

Registrare la stored procedure nel DB

error = sqlite3_create_function(conn, "mcallback", 3, SQLITE_UTF8, NULL, 
                                      &mcallback, NULL, NULL);

Crea il trigger SQLite

Abbiamo bisogno della stored procedure poiché i trigger sono costruiti sopra di essi.

error = sqlite3_exec(conn, "create temp trigger callbacktrigger "
                           "after insert on hello for each row "
                           "begin "
                             "select mcallback(new.first_column, "
                             "new.second_column, new.exclamation_pt); "
                           "end;", 0, 0, 0);

Il trigger è solo temporaneo. In questo modo non rimarrà nel database dopo che l'esecuzione è terminata (del nostro intero programma). Il nostro callback non sarà in giro dopo comunque e il trigger potrebbe (e sarà, data la sua natura) causare problemi maggiori se usiamo il database all'esterno di questa applicazione.

    
risposta data 21.02.2014 - 20:32
fonte