Qual è l'utilità di incoraggiare gli utenti ad imparare SQL e possibilmente la possibilità di eseguirlo?

Scegli una suite di reporting del software al più presto. (Servizi di report server SQL, ad esempio)

Consenti ai tuoi utenti di dirti spesso query e parametri di cui hanno bisogno e di generare effettivamente report ripetibili. Se alcuni dei tuoi utenti hanno acquisito una buona conoscenza di SQL, pensa di creare un database di sviluppo per consentire loro di creare rapporti.

Ho lavorato per una società che non aveva una suite di reporting, ma aveva un sacco di bisogno di rapporti ed era un gran casino. Ogni azienda di dimensioni ragionevoli avrà rapporti mensili / settimanali.

Cercando di crearli da soli nella tua applicazione (quando hai un report davvero critico che DEVI creare per l'utente) diventa un incubo. Poi dopo è un incubo di manutenzione. Non comprare una suite di reporting ma avere un sacco di rapporti sta assumendo debiti tecnici se me lo chiedi ... finirai per scrivere talmente tante informazioni che potresti comprare dallo scaffale e / o stai facendo cose rischiose come lasciare che i tuoi utenti eseguano SQL.

Lasciare che i tuoi utenti eseguano le loro query ti sta chiedendo dei problemi. Deadlock è la prima cosa che viene in mente.

Puoi iniziare con una conoscenza limitata di sql, ma potresti aver bisogno di fare un po 'di sollievo per loro. Ho lavorato in molte aziende che lo hanno fatto con database per applicazioni interne e di terze parti. È stata fornita formazione formale. Non autorizzare gli utenti fino a quando non sono preparati.

Ecco alcuni aspetti da considerare:

1. Creare una versione di report del database anziché utilizzare il database delle transazioni di produzione, se possibile. Discutere su quanto devono essere tempestivi i dati. Ci sono probabilmente pochissime query personalizzate che si basano su dati fino al minuto. Un server virtuale che può essere risuscitato una volta fatto esplodere può essere molto utile.
2. Non consentire l'accesso diretto alle tabelle. Creare alcune viste o qualsiasi oggetto di database appropriato per gli utenti. Prenditi cura di tutti i join complessi e cerca di forzare il più possibile l'uso di qualche tipo di parametro per limitare la quantità di dati recuperati.
3. Rendi l'accesso di sola lettura.
4. Utilizza uno strumento di scrittura dei rapporti. Gran parte delle loro esigenze aggregheranno i dati a vari livelli determinati dalla tua azienda con filtri e ordinamenti diversi.

Inizia con un piccolo numero di campi disponibili. Se li lasci a loro, li vorranno tutti perché sentono che se non ti danno una lista di 500 campi oggi, ci vorrà troppo tempo per elaborare una richiesta di nuovi campi.

Migliora la conoscenza del database o collabora con un DBA che può aiutare a regolare la quantità di risorse che queste query potranno utilizzare. Ancora una volta, sii severo, ma fai sapere agli utenti che puoi gestire rapidamente nuove richieste con questo sistema molto più rapidamente di prima, quindi non è necessario richiedere tutto in una volta.

Dipende dalla cultura.

C'è qualcosa da guadagnare dall'avere utenti esperti in SQL. Ma se lo fanno a metà strada possono anche ottenere risultati fuorvianti. Devi davvero capire cosa vogliono realmente.

NON DARE MAI all'utente la possibilità di danneggiare la compagnia.

Se vuoi farlo puoi configurare un server di report che si abboni al db di produzione. Oppure puoi impostare alcune visualizzazioni e concedere loro solo l'accesso.

In entrambi i casi puoi modellare i dati per renderli più facili da usare. Ad esempio, crea colonne mese, anno, giorno anziché solo colonne di date. Denormalizzare i dati per eliminare la necessità di join. ecc. Quindi solo

IMO: Troppo pericoloso.

Come altri hanno già detto, anche un semplice accesso in sola lettura può rompere il database in modi orribili: deadlock, performance, ecc .; in linea di principio, offri ai tuoi utenti un modo efficiente di eseguire il DoS-in sul server del database. Tutto quello che un utente deve fare è full-outer-join la tabella più grande del DB su se stessa, usando una colonna non indicizzata. Certo, puoi sopportare ogni sorta di restrizioni e salvaguardie, ma questo è complicato e probabilmente non vale la pena.

Invece, chiediti perché questa configurazione è una necessità percepita. Cosa rende gli utenti esigono un flusso così infinito di nuove query? Ci sono degli schemi ricorrenti che puoi distillare tra tutte quelle domande? Quindi progettare una soluzione che consenta agli utenti di generare in modo flessibile i report che desiderano. Le possibili soluzioni includono suite di reporting disponibili in commercio; un DSL semi-sandbox che espone il modello di dati del dominio in modo interrogabile, ma senza il pieno potere distruttivo di SQL; o un'interfaccia utente personalizzata che gli utenti possono utilizzare per comporre le query desiderate in un modo simile a una GUI desktop-applicazione.