Per apprezzare ancor più il valore dei DBMS NoSQL, vale la pena considerare le loro differenze rispetto al mondo relazionale in generale.
Database relazionali: caratteristiche principali
Parlare di DBMS relazionali significa pensare ad un agglomerato strutturato, in cui i dati sono:
- ripartiti in tabelle
- stratificati in righe record
- collegati, trasversalmente alle tabelle, grazie alle cosiddette relazioni
- esaminati tramite query scritte in SQL in cui il meccanismo principe è il
JOIN, che aggrega orizzontalmente più tabelle trattandole all'unisono come se fossero una sola; - creati, cancellati o modificati tramite ulteriori comandi SQL.
- i
JOIN: nonostante la loro efficacia, queste operazioni coinvolgono spesso più righe del necessario - soprattutto se le query non sono ottimizzate - limitando le performance delle interrogazioni eseguite; - struttura rigida delle tabelle
- conflitto di impedenza O/RM
- proprietà ACID
- la struttura dei dati non è definibile a priori. Pensiamo ad esempio alla variegata gestione dei contenuti che impongono oggi i social network o gli applicativi web per la gestione dei contenuti;
- i dati disposti nei vari oggetti sono molto collegati tra loro e - situazione aggravata da una loro gran quantità - il
JOIN - è necessario interagire molto frequentemente con il database, volendo evitare conversioni onerose tra record e oggetti, nè tanto meno ricorrere all'utilizzo di O/RM o altre librerie specifiche;
- necessitiamo di prestazioni più elevate, potendo considerare troppo stringenti le proprietà ACID per il nostro campo di applicatione.
Limiti dei database relazionali
I quarant'anni di dominio del paradigma relazionale non sono stati solo costellati di successi, ma hanno talvolta messo in luce alcuni limiti nel loro utilizzo. Per esempio, è emerso che non sempre i DBMS tradizionali si dimostrano in grado di gestire quantità di dati molto grandi, se non al prezzo di performance molto più limitate e costi piuttosto elevati. Riepiloghiamo i principali punti di debolezza ravvisati nell'uso dei DBMS relazionali:
Quando il NoSQL conviene
A questo punto è lecito chiedersi quando è conveniente utilizzare un approccio NoSQL piuttosto che relazionale. In generale, conviene scegliere l'approccio NoSQL quando:
I suddetti motivi non sono gli unici che porterebbero ad optare per NoSQL, ma sono sufficienti per gli scopi di questa guida.
Quando non rinunciare al modello relazionale
In moltissimi casi, il modello relazionale rimane l'opzione migliore. Innanzitutto, esistono DBMS relazioni ormai consolidati da decenni, supportati da una gran varietà di strumenti: pensiamo a Oracle, MySQL o SQL Server di Microsoft. Inoltre, la struttura rigida che richiede non è necessariamente un problema, e talvolta può costituire un vantaggio (soprattutto se si devono modellare dati molto strutturati). In tali contesti, la duttilità del NoSQL non appare un requisito fondamentale. Inoltre non è da dimenticare che le nuove tipologie di approccio ai dati offerte dal NoSQL si stanno facendo largo in prodotti relazionali blasonati, offrendo comode vie di fuga e scenari di integrazione nuovi, senza rinunciare alla persistenza in senso tradizionale: si pensi, ad
esempio, ai nuovi tipi di dato introdotti in PostgreSQL, di cui si è già discusso su questo sito.