SQL01 - Dynamic Schema e Schemaless Tables. Si puo' fare!

#CDays13 – 27 e 28 febbraio 2013

Davide Mauri

SQL Server MVPFounder & Mentor - SolidQ

dmauri@solidq.comTwitter: @mauridbhttp://www.davidemauri.it

Grazie aSponsor

Davide MauriMicrosoft SQL Server MVPWorks with SQL Server from 6.5, on BI from 2003Specialized in Data Solution Architecture, Database Design, Performance Tuning, BIPresident of UGISS (Italian SQL Server UG)Regular Speaker @ SQL Server eventsConsulting & TrainingMentor @ SolidQ• Italian Subsidiary

dmauri@solidq.com Twitter: @mauridbhttp://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

DEMODynamic Schema & Sparse Columns

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…

DEMODynamic Schema & XML

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

𝛼

𝛽

26

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

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

DEMODynamic Schema & EAV

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&ATutto il nateriale di questa sessione suhttp://www.communitydays.it/

#CDays13