Com\’è dura la professione!

7 settembre 2006

Qualche divagazione su Rails

Filed under: Programmazione,RubyOnRails — lbell @ 21:02

Orm (Object-relational mapping) è un insieme di tecniche per modellare i dati residenti su database relazionali sugli oggetti dei linguaggi di programmazione object oriented. Serve a spostare la gestione dei dati in territori familiari ai programmatori di applicativi, cambiando il paradigma di programmazione, mappando dati e relazioni gestiti dal database in tipi di dato e relazioni che i programmatori sono abituati a trattare.

Dobbiamo utilizzare queste tecniche continuando a basarci su database relazionali invece di passare a motori di archiviazione object oriented adatti alla memorizzazione degli oggetti ‘da programmatori’ sia perché il database relazionale è utilizzato da tutta una serie di programmi esistenti, sia perché un ripensamento totale del motore di archiviazione è un salto nel buio per quello che riguarda affidabilità e costi senza contare che il cliente finale spesso utilizza strumenti per la generazione di report ed elaborazioni che agiscono direttamente su database.

Per ora dobbiamo tenerci due domini diversi ed utilizzare uno strato di software per metterli in comunicazione. Un grosso inconveniente è che l’interfaccia fra questi due mondi, così come viene realizzata nelle tecniche più diffuse (Hibernate ad esempio), è statica e spesso si aggiorna un modello all’insaputa dell’altro.

Un altro grosso difetto è che vi sono modi diversi di identificare le entità tra i due mondi, per non parlare della corrispondenza fra i tipi di dato. Un oggetto in Java o C++ si identifica con un puntatore o una referenza, mentre un database sfrutta il valore dei suoi attributi, ma in certi casi si può avere una sovrapposizione. Nella programmazione distribuita l’identità di un oggetto non si può più verificare tramite un indirizzo di memoria, a meno di non usare un guid. Nei database d’altronde possiamo evitare di creare una chiave univoca sulle tabelle salvo non riuscire più ad indirizzare singolarmente più record con gli stessi attributi (in questo vi sono similitudini con la meccanica statistica sull’identificazione delle particelle).

L’approccio ad attributi sul database è insoddisfacente; se consideriamo la rappresentazione di una persona possiamo utilizzare come chiave il codice fiscale, ma cosa succede se un codice fiscale che ci arriva da una autorità esterna, si rivela errato o deve essere cambiato? Cosa succede ai dati delle tabelle collegate che lo utilizzano come chiave esterna? Non sarebbe meglio che ogni tabella avesse un campo identificativo interno non assegnabile da programma? Dopotutto una persona è una persona e se riesco a distinguerle nel mondo reale anche senza conoscerne il codice fiscale perché non posso farlo anche nell’astrazione che utilizzo per modellarlo nel mio database?

Ci sarebbe da discutere parecchio di forme normali, di variazioni nel tempo dei requisiti delle chiavi primarie e così via, e qui entra in campo Rails.

Rails sta spopolando nel realizzare una mappatura tra oggetti ‘da programmatori’ e ‘da database’ ed è di uso immediato quando le tabelle sono relazionate tramite campi identificatore. Lo scopo di Rails è di scrivere meno codice possibile sfruttando una serie di convenzioni. E’ possibile utilizzare Rails sfruttando gli insiemi di attributi come chiavi, ma occorre configurare ogni relazione e questo va contro lo scopo di Rails. Quando si usa uno strumento occorre assecondarlo, non combatterlo, oppure è meglio trovare uno strumento più adatto.

L’altro problema spinoso di ORM è il mapping dei tipi di dato che non coincidono perfettamente. Ad oggi la definizione è duplice, occorre definirli sia nel database che nei programmi applicativi utilizzando le categorie disponibili in ciascun campo, aprendo la porta ad una serie di problemi di allineamento e consistenza.

Usare Rails per applicazioni di una certa dimensione ci porta a dover risolvere il problema di come gestire i campi degli oggetti. Al contrario di Hibernate, Rails fa uso del pattern ActiveRecord, quindi non esistono campi predefiniti, ma i campi riflettono il reale contenuto del database. Hibernate al contrario pretende una mappatura esplicita tra i membri degli oggetti e campi; ovviamente i dati in questo modo sono definiti due volte ed occorre preoccuparsi della relativa sincronizzazione.

 

1 commento »

  1. Mi sembra che Rails usi la convenzione che la chiave primaria corrisponden ad un numero che si autoincrementa man mano che si inseriscono i record …

    Tale campo si deve chiamare ‘id’.

    Gianluca

    Commento di Gianluca — 7 settembre 2006 @ 22:20 | Rispondi


RSS feed for comments on this post. TrackBack URI

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.

%d blogger cliccano Mi Piace per questo: