posts - 463, comments - 1515, trackbacks - 139
<< I miei amici ... | Home | Il nuovo blog del Micro Framework .NET >>

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 12.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 12.50 | Alesssandro Scardova
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

> hanno già dimostrato di dare risultati migliori dal punto di vista della scalabilità, della performance e della sicurezza.

come provocazione per ragionare sull'argomento concordo.
come indicazione di lavoro...

di tutte le nefandezze che capita di incontrare quando si legge del codice, la causa più frequente è il tentativo di ottimizzazione.


post come questo sono il male

=> perchè presentano una soluzione senza indicare a quale problema (quando c'è un requisito che quantifica numericamente la capacità di carico attesa e il Db attualmente è il collo di bottiglia che impedisce di soddisfare questo requisito)

=> perchè ignora i il trade-off che un progettista deve valutare (costo degli interventi software e della successiva manutenzione a seguito della complessità/duplicazione aggiunta - costo di una soluzione HW alternativa)

=> perchè a primo avviso sembra una silver bullet (in realtà chi fa ottimizzazione sa che tolto un collo di bottiglia subito si presenta il successivo e ottenere le prestazioni attese è una delicata ricerca di un equilibrio tra le diverse risorse - RAM, CPU, DISCO, RETE - , tra tempi di risposta e tempi di elaborazione complessivi, tra parrallellismo e costi di lock e sincronizzazione -senza ignorare i costi in $$$ e tempi di consegna
08/10/2007 12.59 | Luca Minudel
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 13.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 13.50 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Per par condicio posto il link all'esperienza che si può fare quando un DB non è normalizzato:

http://community.ugiss.org/blogs/dmauri/archive/2007/07/16/i-grossi-problemi-di-un-db-non-normalizzato-aspnet-profile.aspx

Per quanto riguarda l'uso di XML e Blob all'interno di un DB non ci vedo nulla di male...è una cosa che faccio da anni, dal 2000 e prima ancora.

Forse è bene chiarire che normalizzare a tutti i costi non è la strada da seguire sempre e comunque....l'importante è capire a cosa si rinuncia ed a dove si sposta il problema di mantenre l'integrità dei dati...perchè il problema è tutto qui: l'integrità dei dati.

Trovo davvero deleterio il post di Pat perchè evidenziano come la totale ignoranza in materia di RDBMS che è alla base di frasi come "That's why we need all those joins". Se gli sviluppatori come lui in MS avessere implementato DAVVERO il modello relazionale non saremmo quindi a sentire frasi come queste. Quindi è inutile che venga a dire che i db sono morti quando nessuno li hai implementati davvero.

Rimane cmq il fatto che la normalizzazione dei dati è l'unico strumento formale (e quindi sicuro e non dipendante dalle capacità personali, almeno fino ad un certo punto) per essere sicuro di avere dati che si mantengono integri nel tempo.

Questo non vuol dire che deve essere usata fino all'eccesso, in quanto - nel modo reale - è poi sempre necessario fare un tradeoff tra costi-performance-tempi di sviluppo-manutenibilità-espandibilità, ma tacciare una cosa come sbagliata solo perchè è vecchia mi sembra davvero sciocco.

E poi non capisco proprio questa avversione per il "vecchio"....la matematica è vecchia millenni eppure è ancora la base di tutto. Il modello relazionale è BASATO sulla matematica....quindi siamo in un paradosso. Oppure che forse sia semplicemente ora di smettere di criticare le falle dei DB che ci sono in circolazione ed inizare a far pressione sui vender perchè implementino quello che la logica matematica ha dimostrato essere una strada funzionante e corretta ormai 30 anni fa?
08/10/2007 13.56 | Davide Mauri
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 14.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 14.42 | Davide Mauri
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Rispetto il tuo punto di vista ma ovviamente non lo condivido.

Non sono daccordo che Pat abbia calcato la mano e se leggi il suo blog vedrai che non è una affermazione estemporanea, nè (vedi link) lui è l'unico ad essere arrivato a quelle conclusioni.

La diseducazione, a mio avviso, è quando non escludono a priori strade che, tra l'altro, stanno dando i loro frutti.
08/10/2007 15.10 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione


Raffa sai che mi permetto la critica sfacciata perchè la reciproca stima professionale nn è in discussione e quindi divertiamoci pure andando duri al confronto per affinare i ferri del nostro mestiere


> Voglio prima di tutto sottolineare che a me prima di tutto demolire quelle che sono false credenze


questo approccio va bene per un developer smart che inizia ad affacciarsi alla progettazione architetturale.

x un architetto no. ho fatto notare la stessa cosa al mitttico Andrea in un suo post su GUISA.

un progettista di professione dice :

la normalizzazione ha queste caratteristiche: bla bla bla
la denormalizzazione ha queste caratteristiche: bla bla bla

la normalizzazione è la soluzione più semplice quindi è la scelta di default.
qunco ci sono problemi di prestazioni dovute a bla bla bla dopo aver verificato di aver fatto correttamente bla bla bla è utile considerare il tradeoff tra normalizzazione e denormalizzazione valutando le caratteristiche di cui sopra.

e contestualizza il tutto al caso specifico in cui sitrova ad affrontare e al team con cui lavora.
08/10/2007 15.17 | Luca Minudel
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 15.40 | Raffaele Rialdi
Gravatar

# SAP compra Business Object

Un&amp;#39;altra acquisizione non da poco. Io non uso ne uno ne l&amp;#39;altro ma &#232; sicuramente una mossa che
08/10/2007 15.56 | Impedance Mismatch
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Luca sottoscrivo al 1000000%
08/10/2007 16.46 | Davide Mauri
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

> 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.
>
Io più che demolire e ricostruire sarei solo per capire.
Parli di quel Pat li che non è un novellino, parli di architetture enterprise, quindi di fatto hai circostanziato bene quello che sembrava una conclusione più generale.
Cosa che a molti, magari non tanto skillati, può sfuggire, da cui l'equivalenza: denormalizzare è sempre bene per motivi di performance e non è un problema per l'integrità dei dati. Voglio dire, già la cultura informatica media in italia è quelle che è, io scommetto che simili conclusioni possono essere inseguite dai più con i disastri del caso.

> Intendiamoci, la demolizione è sulle false credenze, non sulle tecnologie. Non sto
> demonizzando la normalizzazione ma l'uso che tendenzialmente viene fatto da molti.
>
Cioè, usarla sempre e comunque?
Per tutti in generale è un bene ed è una regola buona e giusta per imparare.
Per chi sa che sta facendo, ma lo deve sapere bene (vedi quel Pat li, e non lo sviluppatore medio di oggi), allora può sentirsi libero di seguire altre strade proficue e non dannose (ma il fatto che siano proficue e non dannose non è per niente un concetto generale, ma valido solo per chi sa che sta facendo, e ripeto, non è la media dello sviluppatore di oggi).

> 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".
>
Si ma messo in questa forma non vuol dire un gran che, è giusto una "postilla" per cercare di evitare flame... :-)
09/10/2007 12.22 | AlessandroD
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 13.05 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

> 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.
>
Ma sono perfettamente daccordo, nel senso che la strada è quella di far rendere le persone consapevoli delle scelte che fanno.
Ma se permetti ad uno che inizia da zero, non gli vado certo a dire che normalizzare è controproducente. Le cose vanno fatte a passi, senza saltarne di importanti, altrimenti poi torna tutto indietro in modo negativo.
Filosofeggiamenti a parte considera anche che, da un punto di vista prettamente pratico e realistico per aziende piccole (e in italia ce ne sono moltissimissime), i team di sviluppo non esistono, cioè ci sono 1, 2 persone e forse qualcuna in più che devono cercare di produrre soluzioni decenti con formazione scarsa e in tempi troppo spesso troppo brevi. In quest'ottica penso che il concetto di "DB avvolto da servizi" sia un po' irrealistico da un punto di vista implementativo, in riferimento ai tempi necessari all'analisi e allo sviluppo. Concentrare tutto nel DB dovendo quindi legarsi per forza a tutti gli strumenti che l'engine mette a disposizione per garantire sia prestazioni che l'indispensabile integrità dei dati, è una scelta necessaria. Per carità, sarà anche sicuramente una questione culturale, ma da sempre per chi inizia vale la regola del "più concentro tutto in un unico punto e in modo decente, meno confusione faccio, meglio vado a fare la manutenzione/debug, meglio è autodocumentativo il lavoro fatto".
Credo che oggi denormalizzare sia necessario solo per motivi di performance, ma questo è legato all'hw, chissà se in futuro con hw più performante alcune soluzioni di oggi saranno ritenute sporche e brutte, e si ritornerà a soluzioni più accademiche?
09/10/2007 14.21 | AlessandroD
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 14.47 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@Alessandro
> Ma se permetti ad uno che inizia da zero, non gli vado certo a dire che normalizzare è
> controproducente. Le cose vanno fatte a passi, senza saltarne di importanti, altrimenti
> poi torna tutto indietro in modo negativo.

Il problema è un po' diverso. Io non dico che non debbano normalizzare, ma che devono sapere che non è "IL" modo con la "I" maiuscola. Se insegni quello e ti aspetti che un giorno quello usi gli strumenti in modo diverso allora no, non sono affatto daccordo.
La normalizzazione è ovviamente solo una delle tante cose. Una volta si partiva a disegnare dal DB, oggi sappiamo che il modello ad oggetti non deve nel modo più assoluto mimare le tabelle del DB altrimenti viene solo un accrocchio.

> i team di sviluppo non esistono, cioè ci sono 1, 2 persone
Lo so benissimo che nella maggior parte dei casi è così... ci vado anch'io in giro.

> il concetto di "DB avvolto da servizi" sia un po' irrealistico
E qui ti sbagli alla grande. Nulla di più facile con le tecnologie di oggi. Solo che vedo tanta pigrizia e paura di quello che *ancora* non si conosce.
Oggi tiri su un servizio con poche righe di codice, meno dei grovigli che facevano in VB6 (io preferivo C++ e mi sono sempre rifiutato di andare in deploy con VB6).

> Per carità, sarà anche sicuramente una questione culturale, ma da sempre per chi inizia vale la regola del "più concentro tutto
> in un unico punto e in modo decente, meno confusione faccio, meglio vado a fare la manutenzione/debug, meglio è autodocumentativo il lavoro fatto".

Terribile, cioè la mentalità di quello che dice che costa di meno quello che conosce. Semplicemente pazzesco.
Poi un giorno spendi due giorni a leggerti WCF e scopri che impieghi 5 volte di meno a fare il progetto. Io la chiamo ottusità.

Ci sono strumenti che ormai si usano solo per abitudine, come il RAID 5, che tranne che in pochi casi *oggi* non ha più senso rispetto ad un RAID 1 o 10. Però tutti si riempiono la bocca a parlare di RAID 5 perché il 5 è maggiore di 1.


Riguardo le Stored Procedure, il tuo discorso mi sta benissimo, ma visto che frequenti gli ambienti SQL, sai benissimo che c'è chi vede con il fumo negli occhi anche solo il pensiero di non usare le stored. Io lo chiamo Talebanesimo.

Ciao :)
09/10/2007 16.45 | Raffaele Rialdi
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.


11/10/2007 22.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 :)
11/10/2007 23.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 11.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.
12/10/2007 22.59 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

GdG
> Soprattutto quando si confondono i singoli i singoli pezzi con l'intero insieme organico dei > pezzi.
>
Per me oggi il livello architetturale e di sicurezza disponibile, non consente di vedere i pezzi come un insieme organico.
Con un DB trattato solo come insieme di tabelle e basta, a nessuno vieta di rovinare l'integrità dei dati facendo impazzire i servizi che ci girano sopra e che dovrebbero costituire l'unica interfaccia verso il DB.
Intendo dire che avere un DB così espone per sua natura a molti più rischi rispetto ad avere un DB forte anche dal punto di vista di gestione autonoma della integrità dei dati. Certo che anche in questi casi basta avare accesso con un account a livello amministratore (e deve esistere visto che i servizi di cui sopra per muoversi liberamente e senza impacci lo dovranno pur usare) e il DB lo rovino comunque, ma come si dice, la superficie di attacco rimane in ogni caso più piccola.
O no?
17/10/2007 14.49 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@AlessandroD. Al contrario le architetture d'oggi consentono di preservare il DB più che mai prima.
In una architettura SOA, il DB non deve più essere esposto, meglio se è addirittura in una sottorete differente. I servizi devono avvolgere il DB ed esporre delle funzionalità ad un livello molto alto e per nessun motivo devono permettere di eseguire qualcosa di differente rispetto a ciò per cui il servizio è stato disegnato. Quindi nessun metodo "generico" o altre cose del genere.

Il servizio deve astrarre una logica rendendo del tutto opaco ciò che sta dietro. L'integrità viene garantita da uno o più servizi con un primo evidente vantaggio. La riconciliazione di eventuali discordanze che possono essere lasciate "by design" dal servizio può essere effettuata con procedure asincrone rispetto all'esecuzione del metodo.
Esempio: cancello la riga master e lascio tutti i details. I details verranno eliminati in uno step successivo lanciando una procedura che renda permanenti le cancellazioni fatte. (caso applicabille sia per la cancellazione fisica che logica).

Inoltre limitare il concetto di integrità alla sola validazione del DB è assolutamente fallace. Ci sono molti altri vincoli che il DB non può controllare (altrimenti si trasforma in un application server) e che invece sono fondamentali per considerare quei dati realmente validi. Questo concetto è imprescindibile e tipicamente fa schiantare di netto le applicazioni client-server che *tutt'oggi* vediamo in giro.

La cosa pseudo-comica è che questo tipo di strategie sono ben note da più di 10 anni. Solo che in Italia non sono mai state attuate nel mondo Windows perché le software house hanno saltato l'epoca COM/DCOM, mentre in giro per il mondo sono tutte cose consolidate da tempo.
http://blogs.ugidotnet.org/raffaele/archive/2005/03/22/12787.aspx ==> "Certo molti in sala hanno dichiarato di progettare ancora secondo la logica client-server e ho visto David piuttosto stupito su questo"
17/10/2007 15.23 | 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 16.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 18.06 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Facciamo così, ci sono link a materiale di esempio da spulciare su questi approccio?
Ma roba funzionante, basata chesso' su DB con dati simil-veri, non tracce logiche con abbozzi di implementazione.
Perché davvero non riesco a capire come un qualsiasi linguaggio che non sia SQL possa essere altrettanto performante e chiaro quando c'è da lavorare su dataset (e sui DB questo si fa...), da cui non capisco costa intendi con codice compilato in DLL più performante delle SP, non seguo il nesso.
18/10/2007 17.12 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

@Alessandro. L'esempio più lampante è eBay che ha pubblicato tutto il suo case-study ripreso da più parti. Il link lo trovi proprio nel primo post di questo thread.
È importante parlare di eBay perché è tra le applicazioni più grosse al mondo e porta prove tangibili della sua scalabilità e funzionamento.
Andrea Saltarello ha pubblicato su Codeplex un progetto che trovo estremamente didattico per l'applicazione dei pattern che stanno dietro a questa strategia. Il suo nome è NSK (Noprthwind Starter Kit basato appunto su Northwind): http://codeplex.com/NSK
Io ho pubblicato l'approccio basato su una collection che ha una serie di caratteristiche avanzate tipiche del dataset (www.codeplex.com/rafcollection).

Quanto ai dataset con me tocchi un tasto molto doloroso. Ho provato in almeno due sessioni che il dataset è da evitare come la peste, che le performance non possono essere ottimali come in un object model e come invece un approccio basato su custom object paghi enormemente di più. Tutte le motivazioni sono spiegate passo passo nel documento che trovi su www.codeplex.com/rafcollection. I dataset sono inefficienti i profiler lo dimostrano.

Il codice compilato in DLL è più efficiente per la logica di business che tragicamente troppo spesso (ed è tipico del client-server) vedo nelle stored procedure, o ancora peggio dentro DTS come si parlava un paio di sere fa a cena che purtropppo sono usati a sproposito. L'estrazione dei dati è paritetica, ma appena ci fai dei lavori sopra (vedi caso eBay) conviene portare tutto fuori e farlo sugli (plurale) application server. Questi scalano, il DB è uno solo.

Altri esempi completi io ne ho ma non te li posso dare visto che sono applicazioni di clienti.

Ad ogni modo ci sono nozioni sparpagliate in giro nel web a partire dai libri su COM/DCOM di una decina di anni fa, ai più recenti Pattern&Practices, al portale SOA di MS, e a quelli corrispondenti del mondo Java.
18/10/2007 21.29 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Ok, eBay, e quanta gente c'è dietro eBay?
Per l'altro materiale citato ti ringrazio e vedrò di trovare il tempo di approcciarlo.
Ad ogni modo, riassumento, a me par di capire che un approccio "nuovo" è utile "solo" per problemi di performance, snaturare il concetto di RDBMS e distribuire tutto in modo trasversale tra DB e servizi (poco sul DB e molto sui servizi) serve per motivi di performance e basta. Non che sia un dettaglio per carità, anzi, per certe soluzioni reali capisco che questo approccio sia necessario, ma appunto è una necessità legata al tipo di soluzione da creare, e non un concetto "nuovo e generale", da cui "i tempi sono cambiati cioè che veniva fatto prima si può buttare" è una dritta in generale sbagliata, per casi invece necessaria.
Comunque, comincio a dare un senso al luogo comune della "lotta" tra dev e dba... :-D
Ciao, Alessandro
19/10/2007 9.19 | AlessandroD
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

C'è tanta gente dietro eBay visto che segue milioni di utenti ... non è ovvio?
Insomma in una piccola azienda se invece di scrivere una grossa UI con un mischione di codice e stored procedure scrivo una dll in più ottengo il pregio che il carico di lavoro viene spostato nel tier intermedio.
- La UI è più piccola e contiene meno "ragionamenti" perché gli arriva un object model pronto all'uso
- Il middle tier o sevizio WCF nei casi più piccoli è una sola DLL in hosting dentro IIS o dentro un Windows Service a seconda delle necessità. Niente impersonation e un uso semplice di sicurezza imperativa e dichiarativa per limitare gli accessi a classi/metodi che forniscono un alto livello di astrazione.
- Sul DB (isolato dal servizio e non direttamente accessibile dagli utenti o da altre app) ci sono i dati, strutturati per soddisfare al meglio le esigenze dell'object model.
Il lavoro totale (se hai le basi necessarie), se lo valuti come completo ciclo di vita dell'applicazione, è certamente minore della classica applicazione client-server.

E poi no, i vantaggi non sono solo quelli di performance (che pure sono quelli più reclamati da coloro che oggi producono gestionali, dove continuo a sentirmi dire che hanno toccato il fondo).
I vantaggi li ho scritti più volte: gestione del ciclo di vita del software, maggiore sicurezza del codice (multi-layer è una delle regole di SDL), maggiore riuso del codice, etc. etc. ...
19/10/2007 9.34 | Raffaele Rialdi
Gravatar

# re: Architetture d'oggi, DB e normalizzazione

Chiarito che non sto insistendo per voler aver ragione ma solo perché la discussione è interessante, dici di tenere moltissima (tutta?) la logica su servizi e strutturare il DB in funzione di questo. Ok, allora però sarà anche necessario prevedere un bel numero di metodi per fare la manutenzione ordinaria dei dati da parte dei dev visto che l'accesso diretto al DB, se pur teoricamente possibilissimo per chi sviluppa, potrebbe rivelarsi una bomba ad orologieria con timer ignoto, cosa magari non rilevata poi per test poco approfonditi e poco certosini (visto che il DB non sarà capace di interdire praticametne niente in modo nativo).
A me è anche questo che fa molta paura in generale, i classici casi di emergenza tamponati sistemati andando a toccare il DB non dovranno più esistere, ma saranno da risolvere comunque prevedendo a priori le emergenze per richiamare i metodi opportuni resi disponibili dai servizi.
Non so, sto parlando di approcci che non conosco, vado solo a naso, e quindi la paura di rischiare di distribuire troppo le implementazioni e generare confusione e possibili stalli dovuti ad anelli della catena che diventano deboli a causa di usi impropri ma possibili (causa turn-over degli sviluppatori, collaborazioni temporanee, improvvisazioni di colleghi, ecc...) potrà anche essere ingiustifcata.
19/10/2007 10.03 | AlessandroD
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 11.18 | Raffaele Rialdi

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 4 and 8 and type the answer here:

Powered by:

Copyright © Raffaele Rialdi