S1Mp3

A causa di qualche post di troppo sui lettori mp3, mi sono ricordato di aver qualche piccolo problema con il mio e quindi mi sono messo alla ricerca di un upgrade del firmware… mi si è aperto un mondo. La famigghia è più grande di quanto pensassi….

Dal sito a cercare di capire quale tipo (board id) di lettore avessi, il passo è stato breve:

Sezionando un Rimax

Sezionando un Rimax

Sezionando un Rimax

Sezionado un Rimax

Alla fine sono riuscito ad ottenere la preziosa informazione, ma solo dopo aver smontato il display LCD ed aver spostato la batteria: ho un SCD049-REV1. Pochi istanti dopo ho realizzato che il board id è praticamente inutile dato che non esistono firmware alternativi a quello standard, ma…

E si’, c’è sempre un “ma”, infatti esiste una specie di sdk casereccio per programmare questi aggeggi e della gente, che per mia sventura è di windowsiana natura, ci sta buttando un po’ di energie per veder di realizzare un firmware opensource.

Quindi mi sono detto, perchè non provare a far girare uno stupido programmino sull’aggeggio, magari ne approfitto per ripassare il caro vecchio assembly Z80?

Dopo un po’ di fatica cercando di raccogliere ed “adattare” informazioni dal SDK in C e dagli esempi in assembly, grazie a questo tool sono riuscito a scaricare questa mia stupenda creazione ottenendo il risultato seguente:

perSbaglio su un S1Mp3

Alla prossima: perSbaglio ;) !

Naturali o surrogati?

Cercando informazioni su un problema avuto con NHibernate al lavoro, mi sono imbatutto nel più classico dei quesiti sul design di tabelle in un DB relazionale: le chiavi primarie devono essere definite su attributi che identificano univocamente l’entità che la tabella rappresenta “naturali” oppure possono essere il classico id automatico “surrogati”?

Ovviamente confrontare questi approcci ha un senso solo se la chiave “naturale” è una chiave composta da più campi e quindi più difficile da gestire rispetto all’equivalente “surrogato” che è sempre un singolo numero.
Non molti giorni fa avevo avuto una discussione proprio con Alessandro sullo stesso tema, quindi oggi ho deciso di approfondire un po’ la questione.

Il risultato come in tutte le cose non è una regola ferrea da seguire e come al solito ci sono fazioni che si scannano senza alcun senso proprio sull’argomento.

Sulla base dei commenti (n.b. commenti) di questo articolo Composite keys are evil e dell’autorità di chi ha scritto quest’altro primary keyvil mi sono fatto una prima idea sui pro e contro.

Le chiavi surrogate non hanno una “funzione descrittiva” dell’entità e ciò è male molto male, sono solo un espediente tecnico per rendere più facile (e sembra di molto) la vita di chi utilizza ORM tipo [N]Hibernate. I “surrogati” hanno un qualche vantaggio in prestazioni che però è tutto da verificare dato che per filtrare un qualsiasi dato in una query si è quasi sempre costretti ad eseguire join ulteriori.
E’ praticamente impossibile sostituire “logicamente” una chiave “naturale” con una “surrogata” pena bug difficili da tracciare ed una base dati “più fragile”, quindi alla fine, anche se non come chiave primaria, sarà sempre necessario definire la chiave “naturale” e probabilmente anche con l’attributo “unique”.

Ho quindi l’impressione che sia “giusto” ragionare sempre in termini di chiavi “naturali” e che sia invece “pratico” affrontare e risolvere alcuni problemi tecnici grazie all’utilizzo dei “surrogati”.

Rimane ora il dubbio: primary keys “surrogate” ed indici univoci “naturali” o viceversa?

Oppure niente “surrogati” in attesa che i vendor di RDBMS e che i vari ORM sistemino le loro magagne tecniche?

P.S.
Per quanto riguarda NHibernate gestire chiavi composite “naturali” mi è costato solo un’oretta per scrivere un paio di classi ed implementare due metodi, so che sono all’inizio, ma mi sto ancora chiedendo: qual’è la difficoltà nell’utilizzo di ORM e chiavi composite? Forse arriverà andando avanti…