Come parte di un incarico di lavoro ho a lungo affrontato una procedura memorizzata gigante e dinamica per la creazione di SQL che viene utilizzata per recuperare un gruppo di articoli di inventario. Questa stored procedure accetta una tonnellata di parametri (forse come 20+) che, a sua volta, attiva e disattiva l'SQL dinamico generato.
Alla fine eseguiamo tutto questo SQL e generiamo un risultato.
Lo spazio pubblicitario, ovviamente, ha regole speciali su chi può e non può vedere determinati oggetti e quanti oggetti possono ordinare, quel genere di cose. Di conseguenza, gran parte di questa logica viene impostata nella stored procedure.
Come puoi immaginare, con le sue risme di SQL dinamico i programmatori della mia squadra non hanno mai avuto la necessità di cambiare questa dannata cosa.
Dato che consideriamo già la procedura memorizzata come un 'endpoint' (lasciamo che la stored procedure gestisca tutto in modo che non ci sia incoerenza, permettendo ad un utente di vedere gli elementi che non dovrebbero, per esempio), penso che questo sarebbe un ottimo candidato per essere trasformato in un vero e proprio servizio indipendente.
Nella mia mente mi immagino di eliminare la procedura memorizzata e utilizzare invece una selezione diretta in una sorta di lista immutabile sul lato dell'applicazione. Dovremmo quindi generare una serie di filtri che preformeranno lo stesso tipo, filtrando i vari bit dell'SQL dinamico che stanno facendo ora e ottenendo un risultato dall'altra parte.
Ciò che mi dà una pausa, tuttavia sono i seguenti:
-
Credo di essere solo ingenuo sul modo migliore per creare una "catena di filtri" come questa. Siamo prevalentemente un negozio di Java, quindi mi sono certamente occupato dell'applicazione di un Predicate a una raccolta e tutto, ma in genere l'ho fatto con pochi filtri. Esiste un buon esempio del modo migliore per impostare una "pipeline di filtraggio", in cui inizi con un elenco di grandi dimensioni e progressivamente lo abbassi o si tratta solo di avere una lista di filtri gigantesca?
-
Quando penso a quanto sopra, mi sembra che stia semplicemente ricreando SQL in un ambiente non SQL e che sembra male. La nostra piattaforma è SQL Server / TSQL e sembra che la creazione di stored procedure / funzioni che accettano tabelle come input sia, se non disapprovata, non ampiamente praticata.
Fare cose interamente in SQL le rende anche molto difficili da testare, dalla mia esperienza.
Come accennato, siamo prevalentemente un negozio di Java, ma sono aperto a suggerimenti da qualsiasi lingua. SQL Server è un po 'meno malleabile, come puoi immaginare.
Ad ogni modo, questo problema mi ha fatto girare la testa per un anno o più e mi piacerebbe sentire i tuoi pensieri!