Dynamic Schema e Schemaless Tables

642 views

Published on

Come gestire un sistema nel quale lo schema dei dati non è definibile a priori? Come poter cercare entità i cui dati stanno su più righe? In questa sessione andremo ad affrontare tutti questi problemi, storicamente tra i più complessi per chi si trova a doverli gestire eppure molto comuni e particolarmente delicati per quanto riguarda le performance.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
642
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Inserite l’eventuale vostro logo in basso a destra
  • Slide da mostrare prima di iniziare la sessione – non rimuovere!
  • http://martinfowler.com/articles/schemaless/
  • http://martinfowler.com/articles/schemaless/
  • Ultima slide, obbligatoria
  • Dynamic Schema e Schemaless Tables

    1. 1. Grazie a Sponsor
    2. 2. 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 Subsidiarydmauri@solidq.comTwitter: @mauridbhttp://www.davidemauri.it
    3. 3. Agenda• Schema, Schemaless & Implicit Schemas• Possibili soluzioni• Conclusioni
    4. 4. 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
    5. 5. Schemaless(?)• Nessuna definizione dello schema. Dati non strutturati – File di testo, file binari (senza metadati)• In poche parole un caos.
    6. 6. Implict Schema• In realtà c’è sempre uno schema implicito – Altrimenti non si saprebbe come trattare i dati
    7. 7. Implicit Schema«Ogni valore al di fuori dello schemaimplicito non può essere gestito in modocorretto» (Schemaless data structures, Martin Fowler)
    8. 8. Pro• Flessibilità – Immediatezza – Estendibilità – Facilità
    9. 9. 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
    10. 10. 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
    11. 11. Cosa dice il saggio?«Schemaless => implicit schema = bad.Prefer an explicit schema» (Schemaless data structures, Martin Fowler)
    12. 12. 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?
    13. 13. Schemaless & RBMS• Sono agli antipodi• Eppure è una richiesta molto frequente – Es: CRM, eCommerce, ecc.• Non stiamo parlando di sola persistenza!
    14. 14. Soluzioni con un RDBMS• Colonne «Custom» – Custom1, Custom2• In-Table Data Structures – Colonne contenenti XML, JSON• Entity-Attribute-Value Models
    15. 15. 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
    16. 16. 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 
    17. 17. Dynamic Schema & Sparse ColumnsDEMO
    18. 18. 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
    19. 19. In-Table Data Structures• Sarebbe bello avere la possibilità di «promuovere» degli elementi XML in automatico – Soluzione: Trigger a/o DAL con SP
    20. 20. In-Table Data Structures• Supporto a JSON assente nativamente, volendo disponibile tramite SQLCLR – Perfomance non ottimale nella ricerca • Non è possibile indicizzare nulla…
    21. 21. Dynamic Schema & XMLDEMO
    22. 22. 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
    23. 23. 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 
    24. 24. Relational Division Dividend Divisor Result Remainder
    25. 25. 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
    26. 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
    27. 27. Dynamic Schema & EAVDEMO
    28. 28. 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?
    29. 29. Conclusioni• Non abusatene!• Ricordate sempre il saggio  – Se possibile usate lo schema, nel medio e lungo termine è la soluzione che da più benefici
    30. 30. Q&ATutto il nateriale di questa sessione suhttp://www.communitydays.it/#CDays13

    ×