Applicazione aziendale con molte query SQL

Question

Applicazione aziendale con molte query SQL

#1 da (1 voti)

2

Contesto:

Sto lavorando su un database di Access abbastanza grande (che ho ereditato) che ha la sua interfaccia e le tabelle separate. Per far funzionare tutto questo, abbiamo un sacco di query SQL (dozzine). Alcuni puntano a quel database e altri puntano ai nostri datamarts. Il codice in questo momento è da qualche parte intorno alle linee 12k-14k che non è enorme per lo standard di sviluppo del software, ma non così breve da poterlo riscrivere. Inoltre, quel database è alimentato da un modulo che viene distribuito a tutti i nostri client interni.

La mia domanda:

Mi chiedo quale sia il modo migliore per affrontarlo. Mi piacerebbe sapere se c'è un modo migliore per gestire tutte quelle query piuttosto che averle nel codice in variabili stringa. Sono sicuro che è possibile utilizzare i file, ma poi dobbiamo distribuire quei file e questo non può accadere (cioè non voglio che gli utenti abbiano le query SQL a loro aperte).

Esiste un modo pulito (in termini di progettazione) per gestire le query SQL che hanno ancora una discreta quantità di sicurezza (accesso a tali query)?

Per essere chiari, stiamo utilizzando Access 2007 con VBA.

design microsoft-access vba

posta ApplePie 16.05.2013 - 03:49

fonte

1 risposta

Leggi altre domande sui tag design microsoft-access vba

Progettazione per modulo java riutilizzabile che utilizza connessioni DB L'API RESTful è appropriata per servizi di natura quasi computazionale?

score 1 · Answer 1

Sembra che tu stia utilizzando una configurazione Access-to-Access, con i moduli, i report e le query in un file * .accdb e le tabelle stesse in un'altra.

Se vuoi un migliore controllo delle query, spostale - TUTTE - nel backdack accdb. Le query appartengono alle tabelle e le uniche eccezioni dovrebbero essere eccezionali, con motivi chiari e distinti per non essere presenti nel back-end.

Se fosse il mio progetto, programmerei una migrazione da Access-to-Access a qualcosa come Access-to-SQL (o anche Access-to-SharePoint) e poi, se appropriato, è possibile introdurre lentamente altri front-end per l'accesso in sostituzione, come C # -to-SQL o Web-to-SQL.

L'accesso è un contesto desktop, non un contesto web, e se non devi fingere di essere un sito web non dovresti provare a farlo. Ho visto cose eccellenti fatte riguardo le connessioni dirette al server SQL. Non ultimo, puoi utilizzare la sicurezza integrata e le autorizzazioni per oggetto a livello di server.

(E che "se appropriato" è importante. Se l'accesso funziona e si adatta alla tua scala attuale e prevista, non vale la pena abbandonare solo per avere un programma "reale".)