Stavo ragionando sull’estender Fluent NHibernate per automatizzare il processo di produzione delle entità (sempre ammesso che non esista ancora nulla del genere).

Mi sono quindi posto il problema di come fare per leggere i tipi delle colonne di una tabella. Mi risponde Joe Webb sul suo blog:

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT 
   ORDINAL_POSITION
  ,COLUMN_NAME
  ,DATA_TYPE
  ,CHARACTER_MAXIMUM_LENGTH
  ,IS_NULLABLE
  ,COLUMN_DEFAULT
FROM   
  INFORMATION_SCHEMA.COLUMNS 
WHERE   
  TABLE_NAME = 'TABLE_NAME' 
ORDER BY 
  ORDINAL_POSITION ASC;

I cubi, o ipercubi, in sql non sono altro che la rappresentazione astratta della proiezione di una relazione tra le misure e le n dimensioni che lo caratterizzano. All’interno di un cubo OLAP, quindi, vengono immagazzinate tutte le dimensioni e tutti i fatti (cioè i dati) di modo da rendere più veloce la ricerca e l’analisi dei dati.

Ultimamente, lavorando per Almalaurea, mi sono scontrato, assieme ad Alberto, con il problema della realizzazione di un cubo che contenesse tutte le possibili combinazioni dei collettivi a nostra disposizione.
La prima strada tentata, è stata quella di inserire i dati nel nostro database, combinandoli tramite una logica applicativa. Tuttavia questa soluzione era afflitta da un grave problema: richiedeva circa 10 giorni per portare a termine tutta l’operazione

Sono stati momenti abbastanza terribili, perchè siamo stati assaliti dalla terribile sensazione di non aver poi tempo per testare i dati (o addirittura di non terminare in tempo per il golive). Poi la geniale intuzione di Alberto: la funzione CUBE. Ecco la sintassi:

select pippo, paperino
from paperopoli
group by pippo, paperino with cube

Visto che i tempi necessari si son ridotti da 10giorni a circa 1minuto (stiamo parlando di oltre 1milione di record), è stata davvero la chiave di volta di tutto il progetto!

ps: un grazie anche a Massimo che, anche senza saperlo, è stato fondamentale in questa impresa!