Sto progettando un'applicazione enterprise che produce output basato su alcuni dati di input da un'altra applicazione. In questo caso, ho anche creato e quindi controllo l'applicazione di origine e i dati, la struttura del database, ecc., Ma questa domanda si applica anche ai casi in cui sto utilizzando i dati di input di un'applicazione di terze parti, quindi supponiamo che andando avanti.
La nuova applicazione dovrebbe produrre output solo una volta per un determinato set di dati di input; estrarrà i dati dall'origine, produrrà l'output e manterrà lo stato in modo che gli stessi dati di input non vengano elaborati la prossima volta che viene eseguito.
Quello che mi sto chiedendo è quale sia un buon approccio progettuale da prendere nei casi in cui ho bisogno di memorizzare lo stato in modo che non stia estraendo l'intero universo di dati sorgente quando devo solo operare su un piccolo sottoinsieme di quei dati.
Tre opzioni a cui posso pensare sono:
- Modificare lo schema del database di origine di terze parti in modo da poter memorizzare il mio stato lì.
- Interrogare i dati tramite un join tra il database di terze parti e il mio nuovo database e filtrare i risultati all'interno di quella query in base allo stato archiviato nel nuovo database.
- Archivia i dati di origine nel mio nuovo database ed esegui tutte le query sui dati archiviati.
Ho lavorato con applicazioni aziendali commerciali che utilizzano tutti questi approcci, ma ognuno di essi ha i suoi lati negativi:
Con l'opzione 1, uno svantaggio evidente è che la modifica di un database di terze parti è, nella migliore delle ipotesi, scoraggiata dalla maggior parte dei fornitori e, nel peggiore dei casi, esplicitamente vietata negli accordi di licenza. Inoltre, i futuri aggiornamenti del fornitore allo schema potrebbero cancellare dati o fallire a causa di conflitti causati dalle modifiche. La linea di fondo per me, però, è che non voglio memorizzare i dati per un'applicazione "destinazione" in un database dell'applicazione "sorgente", a prescindere dal fatto che io "possegga" entrambi i database o meno, ma soprattutto se la fonte è un'applicazione di terze parti. Se i dati non vengono utilizzati dall'applicazione stessa, non appartengono al suo database.
Con l'opzione 2, uno svantaggio è che i database possono essere migrati su server diversi e se i join non sono costruiti correttamente con nomi di oggetti completi - compresi i nomi di server DB forniti dinamicamente (a causa della possibilità di cui sopra essere migrati su server diversi) - quindi l'applicazione si interromperà. Un altro svantaggio è che i dati di origine potrebbero non essere memorizzati nello stesso formato del nuovo database (ad esempio un DBMS diverso), precludendo così la possibilità di un join. La cosa più importante per me, tuttavia, è il fatto che questo approccio viola Separazione dei dubbi perché il livello dati deve eseguire alcuni chirurgia imbarazzante e discutibilmente inefficiente per rendere le due entità in oggetti di dominio separati o lo strato di dominio deve avere un ibrido bestiale nodoso delle due entità disparate. In ogni caso, odora.
L'opzione 3 mi sembra la migliore, ma ha ancora il rovescio della medaglia sul fatto che ci sia un sovraccarico nel popolamento e nella manutenzione del magazzino. Qualche "processo" deve fare questo. Da dove viene eseguito quel processo ... da un server di medio livello? Con quale frequenza viene eseguito e cosa succede se l'applicazione richiede dati non ancora aggiornati? Chi lo amministra?
Qualcuno sa di un altro approccio che non ho preso in considerazione, o qualcuno può offrire qualche idea di uno qualsiasi degli approcci di cui sopra ha (per esempio, suggerire modifiche agli approcci che precludono i lati negativi o spiegami perché un approccio è il migliore nonostante i suoi lati negativi)?