Recentemente mi sono trovato con l'esigenza di dover implementare diverse relazioni uno a uno su una base dati. Come sicuramente saprete implementare relazioni uno a uno tra tabelle alla fine corrisponde da un punto di vista logico a implementare tecniche di ereditarietà tra tabelle.
Se per esempio il dominio della mia applicazione prevede l'entità Autoveicolo che a sua volta può specializzarsi in Autovettura e Motovettura sicuramente posso creare tre tabelle con la tabella Autoveicolo legata da relazioni uno a uno sia con Autovettura e Motovettura.
In questo modo posso inserire le proprietà comuni tra le due specializzazioni nella tabella Autoveicolo e quelle differenti nelle altre due.
A questo punto è cosa buona e giusta creare due viste, una Autovetture, con la join tra Autovettura e Autoveicolo, una Motovetture, con la join tra Motovettura e Autoveicolo, chiaramente entrambi in inner join.
In questo modo operando select sulle viste avrò da un lato tutte le Autovetture con tutte le loro proprietà, sia particolari che generali di Autovettura, da un altro la stessa cosa per le Motovetture.
Ma per operazioni di scrittura ?
Per operazioni di scrittura, differentamente da altri RDBMS, SQL Server non permette di modificare dati attraverso viste, a meno che tali viste non presentino una sola tabella nella select di origine o che non siano viste partizionate, sulla cui natura non mi dilungherò ora.
All'inizio rimasi sconcertato da questa cosa, perchè non poter effettuare insert attraverso le viste rendeva il mio lavoro più tedioso, in quanto avrei dovuto implementarle a codice nel data layer.
Cercando con più attenzione ho però trovato una cosa molto utile, che addirittura permette di fare cose che vanno ben oltre quel che mi serviva.
Mi riferisco alla clausola INSTEAD OF per la creazione di triggers su viste.
Praticamente è possibile creare dei trigger sulla vista che di fatto operano quello che a me sembra a tutti gli effetti un override sulle funzionalità primitive di scrittura, ossia INSERT, UPDATE, DELETE.
Questo non solo permette di poter operare insert su viste con relazioni uno a uno , ma addirittura implementare controlli di congruenza per dirottare le operazioni di scrittura su altre tabelle oppure per o per evitare proprio di scrivere sulla base dati.
Riporto di seguito il riferimento alla documentazione presente su MSDN riguardo questa tecnica.
http://msdn2.microsoft.com/EN-US/library/aa175158(SQL.80).aspx
Appena troverò tempo vedrò anche di pubblicare all'interno della mi area progetti le soluzioni da me adottate che fanno uso di questa tecnica.
Termino facendo notare come personalmente la cosa che trovo interessante è la possibilità di poter realizzare basi dati con un approccio logico ad oggetti e poter poi utilizzare i triggers INSTEAD OF come override delle entità create dei metodi di INSERT, UPDATE e DELETE in modo nativo su DB.
Magari questa tecnica potrebbe far storcere il naso ai puristi del tre livelli. Ma faccio notare che la logica dei trigger è chiaramente solo logica di accesso ai dati in scrittura per cui se non ho problematiche di portabilità su altri RDBMS trovo molto più comodo ritrovarmi l'implementazione dei metodi di scrittura delle mie entità come ridefinizione degli statement nativi dell'SQL in modo da non dover cambiare il codice dell'applicativo in caso di cambiamenti in corsa. Saluti.