Osservazione automatica delle modifiche nelle tabelle del database

3

al momento sto lavorando a un progetto con la seguente impostazione:

  • Esiste un'applicazione proprietaria che esegue transazioni su un database Microsoft Access (che in realtà è memorizzato come file .mdb)
  • L'API dell'applicazione non ha abbastanza funzionalità per i requisiti che abbiamo di fronte
  • La nostra applicazione ha accesso diretto al database

Stiamo progettando un'applicazione C # che deve reagire agli eventi che non vengono attivati tramite l'API, quindi l'unico modo in cui posso pensare è di osservare il database direttamente e reagire di conseguenza agli eventi personalizzati.

Un approccio sarebbe probabilmente quello di interrogare il tempo del DB attivato e reagire, ma questo probabilmente porta a problemi di prestazioni quando il DB è grande. Preferirei apprezzare un approccio, in cui il DB stesso notifica la nostra applicazione se si verificano eventi specifici.

EDIT: l'applicazione proprietaria è uno strumento di modellazione Enterprise Architect, quindi il numero previsto di utenti concorrenti non supererà sicuramente 10 utenti e la dimensione del database non sarà superiore a 50 MB. Sarebbe probabilmente una soluzione accettabile per esternalizzare l'attività di polling in un thread separato e notificare il resto dell'applicazione per eventi?

Riguardo al numero di utenti e alle dimensioni del database, quale carico può gestire il database di MS Access?

Esiste un modello / approccio ben noto per questo tipo di problema e se non ne conosci qualcuno, come affronteresti questo problema?

    
posta McMannus 04.06.2013 - 13:59
fonte

3 risposte

0

La soluzione più comune per questo tipo di problema è: provare a progettare l'applicazione C # in modo che non debba reagire alle modifiche all'interno del database. Anche quando si utilizza un database client / server "reale" in cui sono disponibili trigger come trigger, la maggior parte delle applicazioni client / server evita la necessità di un "modello push" in cui il server deve inviare un "evento trigger" al client. In effetti, ci sono solo pochi database che forniscono un tale meccanismo. In genere, le applicazioni client non si basano sul recupero di tutti gli eventi, poiché talvolta la rete tra client e server potrebbe non riuscire.

Naturalmente, non conosco i tuoi requisiti e quanto spazio è necessario per dirigerli, e alcuni requisiti possono essere davvero difficili da implementare senza una meccanica degli eventi appropriata.

Se hai davvero bisogno di questo, immagino che il polling sia l'unica opzione che hai.

Would it probably be an acceptable solution to outsource the polling activity in a separate thread and notify the rest of the application by events?

Tecnicamente: probabilmente sì, ma devi misurare le prestazioni per il tuo caso specifico. Fattori cruciali sono la quantità di dati che deve essere scansionata in ogni ciclo e quale latenza è accettabile (i secondi? Ok. Milisecondi o meno? Possono diventare difficili).

    
risposta data 04.06.2013 - 22:52
fonte
3

Microsoft Access (2010+) ha macro di dati che sono come i trigger, ma non credo che vengano eseguiti a meno che un'applicazione Access sia in esecuzione o se una connessione ODBC li riconosce. Potresti non avere la possibilità di aggiungerli.

Non è troppo per avere un polo di servizi nel database. Per quanto riguarda le tue prestazioni, la frequenza potrebbe dover essere inferiore a quella che preferisci. Il numero di utenti simultanei influenzerà anche questo. Non hai il controllo su questa app di terze parti per ottimizzare le prestazioni a tale scopo.

Non ho idea se questo è uno schema.

    
risposta data 04.06.2013 - 15:01
fonte
1

Acess ti consente di utilizzare tabelle collegate a tabelle in un altro server SQL in particolare SQL. È possibile migrare i tuoi dati in tale? Quindi è possibile utilizzare trigger o lavori per eseguire il montioring necessario.

    
risposta data 04.06.2013 - 22:31
fonte

Leggi altre domande sui tag