posts - 644, comments - 2003, trackbacks - 137

My Links

News

Raffaele Rialdi website

Su questo sito si trovano i miei articoli, esempi, snippet, tools, etc.

Archives

Post Categories

Image Galleries

Blogs

Links

Architetture d'oggi, DB e normalizzazione

Su come la penso circa le archittture e i database è cosa nota a chi mi conosce. Che questo stia sempre più diventando il trend tecnologico (e non per moda ma per necessità) lo si legge sempre più spesso.

Ed ecco alcuni articoletti che mi sono segnato in questi mesi sulle nuove architetture.

Partiamo con il blog architttura del prestigioso DDJ Architecture blog:

  • Analizzando l'architttura di eBay si dice: "The more major implication here is that when it comes to Internet scale, the database looses its importance"
  • Guardando al ruolo del DB nel post "The RDBMS is legacy" si dice: "it (the RDBMS) isn't built to meet newer challenges like linear scalability, high availability, etc." e ancora "... how a column-oriented database (vs. the RDBMS row orientation) can outperform RDBMs by a factor of 50."

Curioso anche come Mats sostenga la teoria di utilizzare il db con BLOB di dati esponendo solo su certe colonne i dati su cui fare filtri, applicare gli indici ed esporre le chiavi primarie.
Perché curioso? Perché è esattamente la strategia che sto seguendo per un progetto in corso, dove il core di dati è una struttura dati già esistente in XML e la sua scomposizione in righe/colonne sarebbe un disastro totale. In pratica alla scrittura del BLOB segue la scrittura delle tabelle di appoggio dove vengono espansi solo i dati rilevanti per quelle cose che mi aspetto da un database: ricerca, indici, relazioni, etc. Le tabelle di appoggio diventano così uno strumento potente in lettura.

Alla faccia della normalizzazione direte voi, e io ripeto che è il risultato quello che conta e non quello che si diceva 30 anni fa.

Nessuno scandalo, queste cose le ripeto ad amici come Davide da anni, e ora mi sento sempre più di frequente meno solo:

La frase più bella è quella dell'ultima slide della presentazione di Pat: "People Normalize 'Cuz their Professor Said To".

Al solito questo non significa che certi strumenti non siano più utili o che non vadano utilizzati. Dico semplicemente che le immutabili certezze che hanno accompagnato il database design per tanti anni sono crollate e oggi in tanti casi ha senso considerare strade alternative che hanno già dimostrato di dare risultati migliori dal punto di vista della scalabilità, della performance e della sicurezza.

Print | posted on lunedì 8 ottobre 2007 15:10 |

Feedback

Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Posso dirti che è l'approccio che ho seguito con successo per un un progetto qualche anno fa dovo lo schema dei dati varia nel tempo (in quel caso in base ad una legge regionale) in pratica espongo solo alcuni dati 'chiave' ma i dati veri e propri sono in un file xml immagazzinato come blog. Il file viene comunque validato da uno schema xsd assicurandone la conformità. Il sistema ha resistito ben 17 versioni della legge regionale ;)
08/10/2007 15:50 | Alesssandro Scardova
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Luca, non so se ho capito bene il senso del tuo post, quindi provo ad interpretare.
Voglio prima di tutto sottolineare che a me prima di tutto demolire quelle che sono false credenze e cominciare a valutare una soluzione per i suoi risultati e non perché sono scritti sui libri.

Se quando parli di "post come questo sono il male", a me sembra invece che le motivazioni che addici per spiegarne il perché non siano applicabili a questo post:
- ho citato il caso a cui sto lavorando spiegando perché la normalizzazione non sarebbe stata applicabile
- ho detto chiaramente che non è un silver bullet ("non significa che certi strumenti non siano più utili o che non vadano utilizzati")

Infine l'aggiunta di hardware è citato nei link che ho postato. Scalare aumentando solo la potenza hardware è uno dei punti che stanno diventando il vero traguardo da raggiungere. I clienti con cui ho a che fare concordano pienamente su questo punto.
08/10/2007 16:33 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@Alessandro. Esattamente la stessa strategia. Anche nel nostro caso la validazione XSD è quella che determina l'approvazione sul DB dei dati. Da notare che l'inserimento viene fatto ugualmente ma i dati sono marcati in modo logico con un flag che determina la sua validità. Questo per permettere all'utente di salvare il suo lavoro prima di aver terminato l'immissione completa.
08/10/2007 16:50 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@Davide, mi spiace che non conosci Pat Helland. Non è uno sviluppatore ma uno dei più famosi architetti che nella sua carriera annovera:
- è stato a capo del team di Microsoft Transaction Server e del Dristributed Transaction Coordinator
- è stato uno degli architetti del service broker di SQL 2005
- ha fatto per qualche anno l'architetto della struttura di Amazon
- è tornato recentemente in MS per dare il via alle nuove architetture
Non credo ci sia altro da aggiungere.

Laddove il DB può essere totalmente avvolto da uno strato di servizi, per quanto concerne l'integrità, questa non deve necessariamente essere tale sul DB. Integrità spesso va ben oltre alle mere relazioni dentro il DB. Io preferisco parlare di validazione che include anche l'integrità dei dati.

Io no ho avversione per il vecchio. Ho scritto "Al solito questo non significa che certi strumenti non siano più utili. Dico semplicemente che le immutabili certezze che hanno accompagnato il database design per tanti anni sono crollate ... ", frase che dice molto chiaramente quello che penso.
08/10/2007 17:25 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

"per quanto concerne l'integrità, questa non deve necessariamente essere tale sul DB" sai che io la penso molto diversamente, quindi non entro nel merito della questione. Abbiamo due idee opposte e lo sappiamo.
Il mio commento ha li semplice scopo di fornire ai lettori un'altra chiave di lettura.
Che Pat si un ottimo archiettetto non lo discuto...che abbia forzato un pò troppo la mano nel suo post IMHO è altrettanto vero: post così di parte sono semplicemente inutili e diseducativi.
08/10/2007 17:42 | Davide Mauri
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Luca, ne fai una questione di impostazione :) beh questi sono le due facce della stessa medaglia.
Se, da quello che vedo in giro, la maggior parte del mondo dello sviluppo italiano è ancora sul client-server, è doveroso prima assicurarsi che le false credenze siano abbattute.
Vedo un Pat Helland, che vive in un ambiente certamente ben preparato e con una quantità notevole di enterprise, sfoderare un tono ben più polemico ed estremo e non posso che concordare che questo è l'unico approccio possibile. Demolire e ricostruire.

Intendiamoci, la demolizione è sulle false credenze, non sulle tecnologie. Non sto demonizzando la normalizzazione ma l'uso che tendenzialmente viene fatto da molti.
Infatti scrivevo: "le immutabili certezze che hanno accompagnato il database design per tanti anni sono crollate" e prima che "Al solito questo non significa che certi strumenti non siano più utili o che non vadano utilizzati".
08/10/2007 18:40 | Raffaele Rialdi
Gravatar

# SAP compra Business Object

Un'altra acquisizione non da poco. Io non uso ne uno ne l'altro ma è sicuramente una mossa che
08/10/2007 18:56 | Impedance Mismatch
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Luca sottoscrivo al 1000000%
08/10/2007 19:46 | Davide Mauri
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Alessandro, non sono il tipo che scrive per evitare il flame e basta. Se ho da dirla, la dico e il mio blog mi è testimone.
Ho scritto questo post perché sono arcistufo di sentire parlare le persone di certi argomenti come inamovibili, assoluti, una sorta di tempio.
Vedo mettere stored procedure perché c'è scritto sui libri. Io non dico di non usarle mai, ma spesso, nelle architetture di oggi sono un clamoroso boomerang.
Vedo normalizzare tabelle e usare l'integrità referenziale perché l'hanno letto sulle bibbie di 30 anni fa. Se però il DB è avvolto da uno strato di servizi questo non serve e il caso eBay dimostra che regge su carichi che probabilmente sono i più alti al mondo.
Io mi lamento del fatto che molti fanno perché qualcuno gliel'ha detto e non perché ci mettono la testa e riflettono.
Basta con lo studio da scolaretti della poesia a memoria... tutto qui.
09/10/2007 16:05 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

> Vedo mettere stored procedure perché c'è scritto sui libri. Io non dico di non usarle mai,
> ma spesso, nelle architetture di oggi sono un clamoroso boomerang.
>
Ah, altra cosa, visto che l'esigenza non di usare sp è basata sul fatto che creare codice T-SQL dinamico da eseguire al volo in certi contesti aiuta ad avere prestazioni migliori, io ricordo che sempre in quei contesti può capitare l'uso di sp_executesql si riveli peggiore (dal punto di vista delle performance) rispetto all'uso di una sp equivalente.
Infatti mentre per le sp è possibile che il chiamante indichi la volontà di avere un piano di esecuzione ricreato ex-novo a causa di distribuzione dei dati particolari per cui per ogni set di parametri è bene abbia il suo piano elaborato ad hoc, questo non accade con sp_executesql che, a parità di query, genera 1 e 1 solo piano riusato fino alla sua "naturale" scadenza indipendentemente dal ventaglio dei parametri forniti durante gli enne richiami.
In questi contesti, per esempio, le sp battono in prestazioni l'uso di sp_executesql.
09/10/2007 17:47 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Raf, non sai quanto mi divertono queste discussioni :-)
Soprattutto quando si confondono i singoli i singoli pezzi con l'intero insieme organico dei pezzi.


12/10/2007 01:58 | Gabriele Del Giovine
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Non credo di aver capito bene cosa intendi, ma mi fa piacere che ti divertano :)
12/10/2007 02:45 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Forse mi sono perso qualcosa, ma mi risulta che da un pezzo (Oracle 9, per dirne una) negli RDBMS esistano funzionalità di datawarehousing che permettono di aggirare i problemi prestazionali della normalizzazione. Le "viste materializzate" presenti già in Oracle 9 (cioè viste salvate come tabelle, che in effetti introducono una ridondanza dei dati) ne sono un esempio...
12/10/2007 14:29 | Silvestro Roberto
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@Roberto. Non conosco quelle caratteristiche di Oracle con cui ho avuto molto poco a che fare.
Il mio dicorso è cmq più architetturale che di specifica implementazione tecnologica.
Per esempio Oracle permette anche di scaricare il lavoro su più server, questo però non significa che sia la scelta architetturale migliore. È certamente meglio, con le attuali architetture alleggerire il suo carico sugli application server.
13/10/2007 01:59 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Il discorso mi è chiaro, ma continuo ad avere fortissimi dubbi sulla possibilità concreta di affrontare questo scenario in soluzioni non enterprise e in team a persona singola a quasi.
I tempi di sviluppo e di test sono per forza di cose più alti dovendo far stare in piedi una infrastruttura completa sopra il DB. Da cui i criticissimi, importantissimi e certosini test del caso per essere certi che i servizi manipolino dati sempre in modo consistente, quando avendo un E/R che utilizzi di suo tutti i constraint offerti dall'engine è impossibile cannare nella manipolazione dei dati. Certo è vero che come dici certe regole di businnes non possono essere implementate completamente solo in modo dichiarativo ma attraverso codice eseguito ad hoc in momenti opportuni, ma pure in questo caso, in scenari piccoli e reali, se il codice è rappresentato da sp nel DB, se ne esce in modo monolitico ma sicuro.

Diciamo sicuramente che il voler portare anche in realtà e progetti piccoli l'approccio "servizi centrico pure per quanto concerne l'integrità dei dati", darebbe un bel giro di dindini in più per i consulenti, questi si, è sicuro... ;-)
17/10/2007 19:09 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Alessandro, non lo dico per soldi, se questo è quello che intendi. Chiedi a chi mi conosce e avrai solo conferme.
A me sembra che il rifiuto delle nuove architetture sia un problema delle persone che non hanno più voglia di imparare, e che pretendono che il loro bagaglio culturale debba per forza durare tutta la vita.
Io imparo tutti i giorni qualcosa di nuovo, ma non tutti sono disposti a fare altrettanto.

La logica a servizi differisce per una questione di testa di chi scrive e non introduce affatto complessità ma semplifica molto. Basti pensare al versioning e alla riduzione del ciclo di vita dell'applicazione che sono le problematiche più complesse nel software.

Ci sono molte persone che mi danno ottimi feedback sui consigli che gli ho dato per vecchie implementazioni n-tier basate ancora su remoting.
- Oggi con WCF semplifichi in modo drastico tutto il codice. Un serivizio è roba di poche righe di codice
- Le sp non sono strong-typed e difficili da testare a fondo. La logica scritta in C#, eventualmente con plugin (quindi facile da upgradare) è molto semplice soprattutto dal punto di vista della validazione e della diagnostica.
- La migliore sp subisce periodicamente delle compilazioni che sono molto povere di performance. Il codice compilato in DLL è abissalmente più performante.
.... e via così ...
17/10/2007 21:06 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

La prospettiva che mostri è piuttosto remota seppur possibile. Molte delle applicazioni che ci sono in giro accedono direttamente alle tabelle (anche tra i client-server) e dopo una banale fase di test il software viene banalmente validato perché si vedono i risultati.
Comunque io sono tra coloro che spingono verso una validazione nell'application server e concordo con te sulle preoccupazioni della congruità.

Il vantaggio di eseguire a posteriori dei controlli di congruità del DB sta nel fatto di poterlo fare quando non c'è carico e in modo più complesso di quanto non sia una semplice corrispondenza mater-detail all'interno delle tabelle.
Ad ogni modo non sto dicendo che l'integrità referenziale non si debba usare. Sto dicendo che non è assolutamente indispensabile e che nella progettazione anche questo elemento deve essere vagliato e non dato per assodato.

Quanto all'affidabilità di una validazione eseguita solo sul database, sono assolutamente scettico per tutto quello che vedo in giro. Se guardiamo alla mera pratica, vedo spesso che l'integrità viene eliminata per cambi sullo schema, per query che diversamente danno un sacco di rogne, etc.
Allora visto che gestire il DB con quelle regole non solo non è semplice (anche per un dba medio) e non fornisce delle garanzie sufficienti a garantire la vera congruità dei dati (vedi righe zeppe di null, etc.) allora è certamente meglio avere una validazione in software.

Una applicazione è come una squadra. Non puoi avere un DB che abbia dati e garantisca la loro congruità se tanto chi li elabora sta altrove. Il DB faccia il suo lavoro che l'application server farà il resto. Si deve lavorare in modo coordinato.
19/10/2007 14:18 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Pensavo di trovare qualche spunto interessante, ma purtroppo devo dirmi deluso: quanto mi annoiano questi dibattiti "filosofici"! E quanto trovo arrogante l'atteggiamento di chi scrive certi articoli (non mi riferisco a QUESTO articolo, ma quelli citati dallo stesso) ponendosi al di sopre di tutti solo perchè si è convinti (a torto) di essere tra i pochi eletti a riuscire a pensare "diverso"!
Comunque sono contento di essere un professionista "autodidatta" e non aver avuto nessun professore a dirmi cosa sia giusto fare o non fare, e quindi poter normalizzare e denormalizzare quando e come lo ritengo più opportuno... ah, già, se non sbaglio questa cosa viene detta "ottimizzare"... beh, io la chiamo semplicemente "lavorare", perchè da ignorante autodidatta quale sono, non conosco altro modo di procedere! ^_^
18/03/2010 17:36 | apg
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

anche il post qui sopra mi sembra fuori dalle righe, io odio gli estremi, i "professori" e gli "autodidatti" che si celebrano in quanto tali.

il db va pensato ottimizzato in funzione del suo lavoro, cioè garantire l'integrità dei dati. poi si aggiusta, e su questo ci sono diversi approcci, anche empirici e basati sull'esperienza, in modo da ottimizzarlo...
19/03/2011 12:45 | yner
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET