Recentemente ho aderito a un team che lavora su osservazioni radar. Il team ha accesso a un repository di software (scritto in C ++) utilizzato per trattare queste osservazioni, ma il loro lavoro è focalizzato sulla ricerca, non sullo sviluppo del software.
Ci sono varie variabili associate alla lettura e all'analisi delle informazioni radar, e sono attualmente memorizzate come variabili locali (da qualche parte) nel software C ++ sopra menzionato. È normale che un ricercatore desideri interrogare alcune di queste variabili per la loro ricerca. Oggi ho scoperto che la pratica standard qui è di controllare un nuovo ramo del codice, modificarlo per stampare ciò che si desidera, e quindi ricostruire ed eseguire il codice localmente. Questo codice modificato non viene mai ricontrollato, poiché è troppo localizzato per essere utile a chiunque altro.
Per me, sembra una pessima pratica (anche se non ho sviluppato software così a lungo, quindi forse uno di voi mi correggerà). Ho sempre sostenuto che il controllo della versione (hanno usato una forma modificata di SVN) dovrebbe essere usato principalmente per apportare modifiche al codice che si intende ricontrollare , e non dovrebbe mai essere usato per fare query una tantum. Questo è ciò che SQL è per.
Purtroppo, non sono affatto sicuro di quanto sarà facile implementare un front-end SQL per questo programma. Al momento, tutte le informazioni vengono archiviate in variabili C ++ locali in vari moduli del programma. Ho avuto due idee su come risolvere questo problema:
- Scrivi una funzione (probabilmente con la riscrittura del codice esistente) che scrive tutte le informazioni che potrebbero essere utili in un database in qualche parte del software del database, utilizzando le librerie standard. Quindi gli utenti possono eseguire questo programma su alcuni dati e scrivere query SQL sul database risultante, utilizzando il parser integrato del software del database.
La cosa positiva di questo approccio è che il lato SQL delle cose (al contrario del lato del database) è interamente gestito dal software esistente. Lo svantaggio è che richiede agli utenti di costruire l'intero database anche se vogliono solo una piccola query. Il team si occupa spesso di grandi quantità di dati in arrivo su base oraria, e potrebbe non essere pratico continuare a costruire database enfatici quando si è interessati solo a piccole query. L'altro problema è che l'organizzazione nel suo complesso è riluttante ad installare un nuovo software sui computer della società e potrebbe essere difficile installare un software di database appropriato.
- Utilizzare una libreria di parser SQL standard per C ++ per interrogare che interroga in qualche modo le variabili locali rilevanti nel programma del C ++ come se fossero memorizzate in un database . Quindi se ho passato la query SQL
SELECT RadarID, Height, Signal Strength, Wavelength FROM RadarObservations WHERE Date = '03/07/2015'
allora il programma mi assegnerebbe tutti i campi specificati per le osservazioni radar il 03/07/2015, senza creare l'intero database, ma ottenendo i valori direttamente dalle variabili locali in C ++ dove sono memorizzati.
Dei due, l'opzione (2) sembra più attraente, ma dubito che sia persino possibile. Qualcuno ha esperienza con entrambe le opzioni, o qualcuno può suggerire qualcosa di diverso? Una linea di condotta potrebbe essere quella di avere una build a rotazione che costruisca i database ogni giorno in modo che le persone possano interrogarli, ma le persone qui sono interessate anche ai dati storici e tenere su tutti questi database potrebbe porre problemi di archiviazione.