Pattern per l'app SQL data mining

1

Abbiamo un'app che viene utilizzata per il data mining sul nostro database client.

Gli usi tipici includono ottenere un elenco di client e i loro indirizzi e-mail, eseguire report sulle transazioni degli utenti tra determinate date e client di ritorno che vivono in un'area specifica.

I requisiti funzionali di alto livello sono:

  1. Ogni query di data mining deve essere in grado di esportare in Excel.
  2. I parametri devono essere supportati (in modo da poter filtrare i risultati, ecc.).
  3. Altre app dovrebbero essere in grado di accedere a queste query e ai relativi risultati.

È stato implementato come segue:

  • Viene creata una funzione di database per ogni query SQL.
  • C'è anche una tabella che contiene i dettagli di ogni funzione e i parametri richiesti come i loro tipi.
  • Esiste un front-end Web in cui vengono mantenute le query SQL e può essere eseguito ed esportato.
  • Esiste un servizio Web che altre app possono utilizzare per eseguire query. Il metodo per eseguire una query restituisce un set di dati e ottiene i parametri dei passaggi e i relativi valori in XML.

La nostra soluzione attuale funziona, ma ci sono alcuni problemi con il mantenimento delle centinaia di funzioni DB (sarebbe necessario utilizzare le funzioni - non potremmo semplicemente memorizzare SQL nelle tabelle?). Ho anche alcuni problemi di sicurezza riguardo all'iniezione SQL dato che il nostro front-end consente fondamentalmente agli utenti di inserire qualsiasi SQL.

Qualcuno ha dovuto sviluppare qualcosa di simile e quale approccio hai usato? Qual è stato il tuo ragionamento per l'utilizzo di tale approccio?

    
posta woggles 04.07.2011 - 17:28
fonte

1 risposta

2

Non chiamerei questo data mining per dire.

In ogni caso la cosa dell'armadio che ho implementato in un progetto può essere descritta come tale:

L'ho chiamato "Custom Reports" (un singolo modulo per un progetto [è un db sql con più front-end, un sistema eterogeneo integrato con altri sistemi (SMS, CISCO, file server, server di stampa) ecc.]) .

In ogni caso, l'idea alla base del rapporto personalizzato è quella di consentire all'utente di creare quasi tutti i report (utilizzando un generatore di report GUI), quindi consentire all'utente di impostare tutti i report pianificati (ricorrenti) in base alle esigenze. Questi vengono raccolti da un'applicazione di servizio che la consegna via e-mail come Excel / CSV all'indirizzo e-mail che è stato configurato.

È abbastanza facile, è fondamentalmente un ORM rudimentale, la query crea sql dinamico che viene memorizzato nella cache ed eseguito.

La GUI in sostanza modifica i metadati (es. tabelle, campi, filtri, logica booleana, ecc.), una singola classe prende questi metadati e crea la query SQL, ei "parametri" sono disinfettati.

Modifica

Il mio ragionamento per questo approccio era che, se non l'avessi fatto in questo modo, l'applicazione web avrebbe avuto una serie infinita di pagine di "Report" CRUD, che farebbero cose molto ripetitive. O una singola pagina CRUD che finirà per chiamare centinaia di proc memorizzati, che dovrebbero essere tutti mantenuti e creati.

In pratica questo metodo ha ridotto la necessità del 95% di tutti i rapporti che avrei dovuto creare. Ovviamente ci sono alcune query complesse che non possono essere fatte (a meno che non modifico la Meta in SQL Class) in questo modo. Ma va bene, quelle poche domande è solo più facile sbattere un codice SQL codificato a mano ...

    
risposta data 05.07.2011 - 02:20
fonte

Leggi altre domande sui tag