Commenti

Autore: Gianluca SartoriInviato il: 14 ott 2013 - 09.33

Heh! Questione annosa e problema davvero seccante!
Ottima descrizione del problema e delle soluzioni possibili. Grazie!
Un altro modo per girarci attorno è l'uso di OPENROWSET o OPENQUERY usando un server di loopback. Ho usato una tecnica simile in questo post: http://spaghettidba.com/2011/11/16/discovering-the-output-of-dbcc-commands/

Autore: alx_81Inviato il: 14 ott 2013 - 09.55

Già, considera che sono abiutato a modularizzare molto per riutilizzo del codice.
Ma per questo SQL Server non mi è amico, ogni livello che aggiungo, anche se mi da semplicità di utilizzo, a volte mi porta overhead talmente alti da costringermi a mollare.
Grazie per il link Gianluca!

Autore: Gianluca SartoriInviato il: 14 ott 2013 - 10.02

Purtroppo SQL in generale non è amico della modularizzazione. Basta pensare a quanti problemi derivano dall'uso di viste che interrogano viste che interrogano viste all'infinito. Il codice è senz'altro più modulare, ma può diventare un incubo a livello di prestazioni.
Anche a livello applicativo le cose non migliorano, perché in generale la modularizzazione in classi e metodi ci invoglierebbe a riutilizzare codice buono su una singola riga anche quando lavoriamo con dei set di dati, il che ovviamente pone dei problemi prestazionali enormi.
Purtroppo, dal mio punto di vista, la questione non ha soluzione.

Autore: alx_81Inviato il: 14 ott 2013 - 10.06

Eh già.. e io aggiungerei che in fondo.. perchè modulare su SQL Server? Forse è già troppo database centrica la soluzione proposta, ed è meglio estrarre fuori certe logiche, anche per scalare :)

Autore: Gianluca SartoriInviato il: 14 ott 2013 - 10.16

Beh, è un tema complesso e che circola da una vita.
Ogni giorno ho a che fare con gli sviluppatori che mi dicono che la business logic dovrebbe stare fuori dal database.
In una certa misura sono d'accordo, ma lo schema stesso del database è parte della business logic. Dovremmo avere un database completamente schema-less per non avere logica nel database, che in parte è quello che fanno alcuni database NoSQL.
Per me non fa molta differenza dove si mette la business logic, basta che non mi pianti il server :-)
Se poi la perfetta modularizzazione (magari mediata da un bel ORM) genera codice SQL che va a dorso di mulo e vengono da me a cercare un po' di performance, non si stupiscano se la soluzione che offro è nel database e non nel codice applicativo.

Autore: alx_81Inviato il: 14 ott 2013 - 10.20

Ultimamente sto frammentando molto i miei database. A volte preferisco non avere una FK ma ragionare ad entità e componenti..
Comunque, come dici tu, basta che i server reggano :)

SQL Server ed ALM su database

INSERT-EXEC innestati, limiti e (imp)possibili workaround

Scrivi un commento

Commenti