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…