Generazione di query dinamiche: suggerimento per approcci migliori [chiuso]

1

Attualmente sto progettando una funzionalità nella mia applicazione Web in cui l'utente verificato dell'applicazione può eseguire query che desidera dall'insieme predefinito di query con la clausola where che varia in base alla scelta dell'utente.

Ad esempio, la tabella ABC contiene la seguente query Modello chiamata SecretReport

"Seleziona def come FOO, ghi come BAR da MNO dove"

SecretReport può avere parametri XYZ, ILP. Anche in questo caso XYZ può avere valori come 1,2 e ILP può avere 3,4

quindi se l'utente sceglie ILP = 3, otterrà il risultato della seguente query sul suo schermo  "Seleziona def come FOO, ghi come BAR da MNO dove ILP = 3"

Anche in questo caso all'utente sono consentite permutazioni di XYZ / ILP

Il mio pensiero iniziale è che all'utente verrà mostrato un elenco di nomi di Report e ogni rapporto avrà parametri e valori corrispondenti. Ma questo approccio anche se tecnicamente semplice non sembra intuitivo.

Vorrei estendere questa funzionalità a un livello più generico. Tale che l'utente può scegliere una tabella e una query in base alle sue esigenze. Ovviamente non vogliamo che l'utente finale prenda il controllo completo di DB. Ma solo tabelle e campi che sono rilevanti per lui. Al momento stiamo definendo ciò che è rilevante nel codice. Ma voglio che l'amministratore prenda in carico questa funzionalità in modo che possa decidere ciò che è rilevante ed esporre lo stesso all'utente. Dal lato dell'utente dovrebbe essere intuitivo ciò che è a sua disposizione e quali domande può formulare.

Condividi le tue opinioni sul modo più intuitivo di fornire questa funzionalità all'utente finale.

    
posta Gaurav Parmar 09.06.2014 - 13:23
fonte

1 risposta

0

My initial thought is that User will be shown a list of Report names and each report will have parameters and corresponding values. But this approach although technically simple does not appear intuitive.

Non sono d'accordo.

Se i tuoi rapporti non sono espressi in termini comprensibili per gli utenti (cioè intuitivi), allora chi hai scritto per loro?

Crea una serie di rapporti (con "titoli" che significano cose per gli utenti).

Quindi aggiungi i parametri a quei rapporti, sempre con "descrizioni" significative per l'utente). È raro - ma non inaudito - per gli utenti di "parlare in codice" quindi favorire descrizioni su valori codificati (ad es. Cosa fare " 1 "e" 3 "significa?)

Nascosti all'interno dell'applicazione, tutti quei "titoli" e "descrizioni" vengono convertiti nella terminologia del database - tabelle, [join?], campi, condizioni, ecc., in modo da poter creare un po 'di SQL ed eseguirlo effettivamente sul Per conto degli utenti, ma gli utenti non riescono a vedere nulla di tutto ciò. Mai. Nemmeno se l'SQL generato è sintatticamente errato (registra l'errore "reale" in un file, mostra agli utenti qualcosa di banale ma apologetico).

Nota: continuo a dire "Utenti" - plurale .

avrà diverse comunità di utenti, con diversi livelli di accesso a diversi insiemi di dati. Assicurati che la tua applicazione sia in grado di gestirlo e che anche i tuoi "amministratori" lo capiscano. La legislazione sulla "protezione dei dati" varia molto, ma la premessa di base "non permettere a nessuno di vedere qualcosa che non sono autorizzati a" è valida praticamente ovunque e può costarti un sacco di soldi se sbagli.

    
risposta data 09.06.2014 - 15:17
fonte

Leggi altre domande sui tag