Anche oggi sul ng di SQL Server è stata postata la fatidica domanda: "...ma devo scrivere cosi tante stored procedure"?
Si.
Non bisogna avere paura di avere molte stored procedure all'interno di un database, non è sintomo di cattiva programmazione nè tanto meno di poca portabilità.
Le stored procedure permettono di far sì che lo schema del nostro database sia indipendente dalla logica di business e viceversa. La logica di business (molto più correttamente la logica di accesso ai dati) deve "semplicemente" scegliere qual'è la stored procedure (o query se ipotizziamo di lavorare su un db che non supporta le SP) che deve essere eseguita per poter portare a termine la richiesta che è stata fatta, e gestirne i relativi parametri di input e di ouput.
Così facendo il DBA può tranquillamente modificare lo schema del database senza per questo dover necessariamente obbligare gli sviluppatori dell'applicazione ad apportare anch'essi modifiche al codice: le stored procedure diventano - di fatto - l'interfaccia con la quale database e applicazione decidono di scambiarsi i dati. Può succedere qualsiasi cosa all'applicazione od al database ma, fintatochè l'interfaccia non viene modificata, l'uno può (deve!) essere ignaro delle modifiche strutturali apportate all'altro.
Se poi la logica di accesso ai dati viene inserita all'interno di classi ad-hoc diventa anche molto semplice cambiare il database sulla quale la nostra logica di business va ad operare (come il buon AndreaS ricorda sempre, questo lo si può fare tramite un'Abstract Factory).
Non utilizzare le stored procedure perchè si vuole essere compatibili con più database possibili non è una soluzione ottimale. La soluzione ottimale è quella di implementare uno strato di accesso ai dati specializzato per ogni database che si vuole supportare e di questo sfruttare al 100% tutte le funzionalità che ci mette a disposizione. Il motivo di tale affermazione è presto detto: se non lo facciamo avremmo sprecato i soldi investiti per acquistare il database server con tutte quelle funzionalità, che poi, alla fine non usiamo.