Grazie a
Sponsor

Davide Mauri
Microsoft SQL Server MVP
Works with SQL Server from 6.5, on BI from 2003
Specialized in Data Solution Architecture, Database Design, Performance Tuning, BI
President of UGISS (Italian SQL Server UG)
Regular Speaker @ SQL Server events
Consulting & Training
Mentor @ SolidQ
• Italian Subsidiary
dmauri@solidq.com
Twitter: @mauridb
http://www.davidemauri.it

Agenda
• Schema, Schemaless & Implicit Schemas
• Possibili soluzioni
• Conclusioni

Schema
• Definizione «a priori» della struttura dei
dati
• Permette l’inserimento dei dati solo se
compatibili con lo schema definito
• Es: Tabella in un RDBMS, XML Schema,
Classe, Struttura

Schemaless(?)
• Nessuna definizione dello schema. Dati
non strutturati
– File di testo, file binari (senza metadati)
• In poche parole un caos.

Implict Schema
• In realtà c’è sempre uno schema implicito
– Altrimenti non si saprebbe come trattare i dati

Implicit Schema
«Ogni valore al di fuori dello schema
implicito non può essere gestito in modo
corretto»
(Schemaless data structures, Martin Fowler)

Pro
• Flessibilità
– Immediatezza
– Estendibilità
– Facilità

Contro
• Le informazioni sullo schema sono nascoste
– Sono sparse nel codice
• E’ molto difficile governare la confusione che
si può venire a creare
– Es: campi diversi che contengono lo stesso dato
• RagioneSociale vs Ragione_Sociale

Contro
• Molto molto difficile definire dei vincoli di
integrità dai dati
– L’integrità dei dati è un valore da preservare!
– Gli schemi XML non sono nati a caso 
• Le performance in fase di inserimento e
ricerca possono essere problematiche

Cosa dice il saggio?
«Schemaless => implicit schema = bad.
Prefer an explicit schema»
(Schemaless data structures, Martin Fowler)

E se serve ugualmente?
• Ma se effettivamente sono nel corretto
use-case per l’uso di un implicit schema?
• L’unica soluzione è un database
documentale o un key-value store?

Schemaless & RBMS
• Sono agli antipodi
• Eppure è una richiesta molto frequente
– Es: CRM, eCommerce, ecc.
• Non stiamo parlando di sola persistenza!

Soluzioni con un RDBMS
• Colonne «Custom»
– Custom1, Custom2
• In-Table Data Structures
– Colonne contenenti XML, JSON
• Entity-Attribute-Value Models

Colonne «Custom»
• Fino a SQL Server 2008 un problema
• Da SQL Server 2008 le Sparse Columns
vengono in aiuto
– La modifica dello schema deve essere ancora
fatta tramite ALTER TABLE

Colonne «Custom»
• Sparse Columns
– Sono colonne a tutti gli effetti
– Opzionalmente restituite come XML
• «Column Set» column
– Non occupano spazio se non usate 
• Ma ne occupano un po’ di più quando usate 

Dynamic Schema & Sparse Columns
DEMO

In-Table Data Structures
• Supporto completo per XML
– XPath / XQuery
– XML Index
• Performance buone
– Ma non ottimali (rispetto all’equivalente
relazionale)
– Notevole consumo di spazio

In-Table Data Structures
• Sarebbe bello avere la possibilità di
«promuovere» degli elementi XML in
automatico
– Soluzione: Trigger a/o DAL con SP

In-Table Data Structures
• Supporto a JSON assente nativamente,
volendo disponibile tramite SQLCLR
– Perfomance non ottimale nella ricerca
• Non è possibile indicizzare nulla…

Dynamic Schema & XML
DEMO

Entity-Attribute-Values
• Tecnica molto utilizzata
– Ad esempio in Wordpress
• Funziona su qualisiasi RDBMS
– Non richiede funzionalità «speciali»
• Molto discussa e discutibile
– Ma fino a SQL 2005 nessuna vera alternativa

Entity-Attribute-Values
• Le query richiedono l’implementazione di
un operatore non supportato dagli RDMBS
– «Relational Division»
– E’ documentato e ben spiegato nella teoria
• Diventa quindi molto facile da implementare 

Relational Division
Dividend
Divisor Result
Remainder

Relational Division
• L’algebra relazionale ci dice che si
implementa cosi:
– Generare tutte le coppie di valori
– Rimuovere tutte le coppie GIA esistenti
• Cosi che abbiamo tutte le non-risposte
– Rimuvere tutte le non-risposte
26

Relational Division
• Il bello degli RDBMS è che possiamo
prendere la soluzione e scriverla tale e
quale in SQL 
• Applicando opportune semplificazioni si
ottengono anche delle performance molto
buone

Dynamic Schema & EAV
DEMO

Conclusioni
• Si può fare! 
– Performance più che buone
– Bisogna scegliere la soluzione che si adatta
meglio al nostro use-case
• Ricerca di attributi?
• Ricerca di attributi & valori?
• Performance read, write, read/write?

Conclusioni
• Non abusatene!
• Ricordate sempre il saggio 
– Se possibile usate lo schema, nel medio e
lungo termine è la soluzione che da più
benefici

Q&A
Tutto il nateriale di questa sessione su
http://www.communitydays.it/
#CDays13