Di recente mi sono trovato a dover fare della valutaioni per laggiornamento di un ambiente Moodle dove si utilizzano largamente i pacchetti SCORM come modulo di attività
Lo SCORM (Shareable Content Object Reference Model) è uno standard molto utilizzato nell'ambito dell'e-learning per la facilità con cui consente di creare e distribuire si varie piattaforme contenuti formativi
I pacchetti SCORM, comunicano con la piattaforma di e-learnig (in questo caso Moodle) attraverso delle API che consentono di tracciare varie interazioni tra l'utente ed i contenuti didattici, come avanzamento della lenzione, tempo di fruizione, risposte ai quiz, punteggio dei test, ecc.
Tutte queste informazioni vengono registrate a DB attraverso il datamodel di Moodle e fino alle versioni precedenti alla 4.3, la tabella scorm_scoes_track, era responsabile di immagazzinare tutti questi dati.
Come si può leggere in questo post, la comunità Moodle ha deciso di operare un cambiamento importante sulla struttura del db e, a partire dalla 4.3, la scorm_scoes_track non sarà più presente ma il processo di aggiornamento creerà tre nuove tabelle che si occuperanno di tracciare i dati provenienti dagli scorm: scorm_scoes_element, scorm_scoes_attempt e scorm_scoes_value.
Questo dovrebbe migliorare le performance del sistema e facilitare l'esecuzione di report custom. Nella vecchia tabella infatti, ogni diverso elemento che contaddistingue il tipo di dato registrato non è un campo della tabella, bensì il valore del campo "element" e ciò, nel caso in cui si vogliano ottenere dei report custom sui tracciamenti, costringe in alcuni casi e mettere in join la tabella con se stessa più volte.
Ovviamente tale approccio non risulta del tutto indolore, in particolare perché costringe a riscrivere ventuali query per i report custom e perché per siti di grandi dimensioni con molti tracciamenti scorm, può rendere il processo di aggiornemanto piuttosto lungo.
Possiamo vedere qui le operazioni che danno luogo alla nuova struttura, notando per esempio che nel caso si abbia un numero di recod maggiore a 500K, lo script ci da un warning sulla possibile durata importante del processo
Per fare un esempio, il sito che ho preso in esame aveva quasi 200 milioni di record nella scorm_scoes_track il ché può richiedere tempi piuttosto lunghi anche con hardware prestante.
Spero che queste considerazioni possano tornare utili a qualche organizzazione che utilizza Moodle e gli SCORM per la didattica o a sviluppatori che dovranno lavorarci e in tal caso, in bocca al lupo per l'aggiornamento.