Una delle fun­zio­na­lità più utili dei DBMS è quella delle fun­zioni aggre­gate, come MAX o SUM, ad esempio.

Con PostgreSQL si può fare un passo in più, con CREATE AGGREGATE.

La sin­tassi del comando è la seguente:

CREATE AGGREGATE name ( input_data_type [ , ... ] ) (
    SFUNC = sfunc,
    STYPE = state_data_type
    [ , FINALFUNC = ffunc ]
    [ , INITCOND = initial_condition ]
    [ , SORTOP = sort_operator ]
)

Come si vede, dob­biamo imple­men­tare almeno SFUNC che è la fun­zione che viene invo­cata per ogni riga; se neces­sa­rio, pos­siamo anche FINALFUNC, che è la fun­zione invo­cata in chiu­sura, dopo che SFUNC ha aggior­nato lo stato della varia­bile con l’ultima riga. Un esem­pio lo tro­vate in “How To create multi-column aggre­ga­tes”.

La cosa più inte­res­sante di que­sta fun­zio­na­lità è che rende pos­si­bile ope­ra­zioni molto simili (per non dire iden­ti­che) alle fun­zioni di fol­ding.

Questa serie di post sta diven­tando una saga… Come spesso capita, una volta che si ini­zia a dubi­tare, le domande fioccano. 

Di solito, una volta map­pata la tabella sulla classe poi pos­siamo imple­men­tare la cosid­detta busi­ness logic in quella classe. Spesso, però, suc­cede che que­sta busi­ness logic toc­chi più classi con­tem­po­ra­nea­mente; quindi mi sono chie­sto: non sarebbe più sem­plice con­si­de­rare quelle classi come “pas­sive” — per così dire — e imple­men­tarla com­ple­ta­mente al di fuori di esse? Nell’EOF, que­sto equi­vale a map­pare tutte le tabelle con l’EOGenericRecord o una sua sottoclasse.

Inciso: que­sto è un difetto più gene­rale dei lin­guaggi OO: devi sem­pre avere una classe o un istanza di quella classe a cui “attac­care” un metodo. So benis­simo che soli­ta­mente que­sta carat­te­ri­stica non è vista in modo nega­tivo ma sono arri­vato a un’altra con­clu­sione; ne par­le­remo un’altra volta.

Sull’altro ver­sante, quello del data­base, abbiamo tutte quelle ope­ra­zioni come le join e gli aggre­gati (SUM, AVG e così via) che sono molto più facil­mente uti­liz­za­bili diret­ta­mente a quel livello. In que­sti casi le uni­che pos­si­bi­lità sono: aggi­rare la map­pa­tura e mani­po­lare i risul­tati grezzi o defi­nire delle ulte­riori mappature.

Di solito pre­fe­ri­sco usare la prima solu­zione: la map­pa­tura non sarà com­pleta ma copre almeno i casi prin­ci­pali. La seconda appe­san­ti­sce il domain model di entità/classi con uno scopo limi­tato a casi speciali.

A dispetto dei “great blun­ders” (1, 2), per un certo tempo ho tenuto la vocina cri­tica oppor­tu­na­mente al di sotto della soglia udi­tiva; mi sem­bra­vano que­stioni mar­gi­nali e comun­que lavo­rare con l’EOF era diver­tente ed ele­gante, soprat­tutto rispetto a pro­dotti ana­lo­ghi, come Hibernate.

Infatti, ho comin­ciato ad avere qual­che dub­bio serio su que­stioni che non riguar­dano diret­ta­mente la scor­retta ana­lo­gia classe-tabella. Semplicemente, un giorno ho comin­ciato a chie­dermi se, al posto di map­pare il nome del cliente da VARCHAR a String, non sarebbe stato meglio defi­nire una classe ad hoc.

In fondo — mi dicevo — che senso ha scri­vere una cosa del tipo cliente.nome().equals(indirizzo.via()), visto il loro signi­fi­cato è com­ple­ta­mente diverso? È vero, di solito usiamo String per entrambi i valori e anche gli even­tuali vin­coli d’integrità potreb­bero essere molto simili, ma non ha molto senso con­fron­tare un nome con una via.

Purtroppo, per quanto l’idea sia cor­retta, la com­ples­sità del codice schizza alle stelle per­ché non è sem­plice imple­men­tare la cosid­detta “spe­cia­li­za­tion by con­straint”; con l’EOF, in Java, non sono riu­scito a otte­nere risul­tati decenti.

E così ho comin­ciato a ripen­sare il mio approccio.

Il secondo pro­blema nella sup­po­sta equi­va­lenza fra classi di oggetti e tabelle può essere logi­ca­mente col­le­gato al primo ma può anche essere pre­sente per conto pro­prio. Questo secondo errore con­si­ste nell’esporre i pun­ta­tori e le tabelle.

Il noc­ciolo del pro­blema è che,  per defi­ni­zione, i pun­ta­tori sono varia­bili, non valori e il modello rela­zio­nale non con­sente l’uso di varia­bili di tupla o di attributo.

Credo sia un errore minore rispetto al primo e soprat­tutto non molto rile­vante nella discus­sione sugli ORM. Infatti, nel momento stesso in cui creo un map­ping, mi muovo all’interno di un certo ambiente di pro­gram­ma­zione che, di nuovo per defi­ni­zione, non è relazionale.

Ascoltando que­sto pod­cast mi è venuto un attacco di nostal­gia pen­sando a quanto tempo ho pas­sato a usare l’EOF, a quanto ne ho tes­suto le lodi e a quanto poco ne senta adesso la man­canza, avendo cam­biato radi­cal­mente idea.

Oggi penso che gli ORM siano quasi sem­pre la solu­zione sba­gliata, se non per l’indipendenza dai vari dia­letti SQL.

Il pro­blema sta nella sup­po­sta equi­va­lenza fra classe e tabella. La tabella CLIENTE diventa la classe Cliente; le colonne diven­tano diven­tano attributi/ivars/properties/metodi della classe; ogni riga della tabella diventa un’istanza della classe. Semplice, no?

In effetti la ten­ta­zione è forte, ma credo sia un’idea sba­gliata e la ragione è quella defi­nita da Date come “The first great blun­der”. Nota sul link: l’ho messo per como­dità ma rac­co­mando di leg­gere il suo libro “An intro­duc­tion to data­base systems”.

Per molto tempo ho con­si­de­rato le obie­zioni di Date troppo for­mali, quasi cap­ziose, ma mi sba­gliavo. Credo che l’inte­grità con­cet­tuale così pun­ti­glio­sa­mente difesa sia una cosa impor­tante e che senza di essa le pre­messe per un buon design del soft­ware siano minate alle fondamenta.

Se volete dare un’occhiata a un sito ricco di dati, pre­sen­tato in maniera (molto) sobria ma effi­cace, date un’occhiata ad UNData, un sito delle nazioni unite che mostra dati pro­ve­nienti da circa 55 milioni di records.

Alex Bosworth mette alla prova SimpleDB, creando una bacheca (“bacheca”… :-/ non suona otto­cen­te­sca?) per mes­saggi e sco­pre l’acqua calda! Scherzi a parte: fa le sco­perte che capi­tano a tutti i pro­gram­ma­tori, e non solo a loro, quando si passa dal dire al fare.

Ad esem­pio, il non poter ordi­nare i dati, piut­to­sto che l’even­tual con­si­stency, pas­sando per il fatto che SimpleDB non ha sup­porto per le sequence. In un modo o nell’altro è riu­scito ad aggi­rare tutti i pro­blemi, salvo poi sco­prire che a livello di API lo Unicode non è sup­por­tato; e que­sto è vera­mente incredibile.

A conti fatti, il responso è posi­tivo, cal­co­lando che è ancora in beta.

Altri post su SimpleDB.

Ho già par­lato di SimpleDB, il ser­vi­zio per data­base di Amazon.

Volevo solo segna­lare, tra­mite que­sto post, che almeno per ora il tasso di errore sem­bra piut­to­sto alto, anche se non c’è nes­sun det­ta­glio sulle pos­si­bili cause. Speriamo sia un pro­blema limi­tato alla beta.

Sempre nello stesso post viene anche citata una delle que­stioni più discusse di SimpleDB: l’even­tual con­si­stency. Con que­sto ter­mine si intende la capa­cità di un sistema distri­buito di pro­pa­gare in modo affi­da­bile degli aggior­na­menti, senza tut­ta­via garan­tire che lo stesso valore sia coe­rente in tutti i nodi.

Per quanto spesso non sia d’accordo con Dave Winer – anche se la rea­zione più fre­quente che ho è: “E quindi?” – il suo com­mento finale su SimpleDB è esat­ta­mente il pen­siero che ho avuto io:

It’s ama­zing that Microsoft and Google are sit­ting by and let­ting Amazon take all this ground in developer-land without even a hint of a response. It seems likely they have some­thing in the works.

Ed è vero anche per le altre ini­zia­tive di Amazon, S3 e EC2.

In fondo, è ragio­ne­vole pen­sare che l’infrastruttura di Google sia per­sino più robu­sta, distri­buita, sca­la­bile di quella di Amazon, eppure, tutto tace.

Commenti come que­sto: “The Non-Relational DB Strikes Back!” o frasi come questa:

“Many deve­lo­pers sim­ply want to store, pro­cess, and query their data without wor­ry­ing about mana­ging sche­mas, main­tai­ning inde­xes, tuning per­for­mance or sca­ling access to their data.” (Il cor­sivo è mio).

o anche dei miei post pre­ce­denti, mi ricor­dano che spesso si equi­voca fra la per­si­stenza dei dati e il dise­gno dei dati. Sono due cosa com­ple­ta­mente dif­fe­renti: non è suf­fi­ciente seria­liz­zare un grafo di oggetti per avere un database!