Web Log di Raffaele Rialdi

# re: Un motivo in più per usare i Guid come chiavi primarie

Lo sai che con un post del genere scateni la polemica! :-D
Anyway vorrei proprio vedere ogni quanto avviene la pressione del tasto save allo stesso istante su una nuova istanza di una identita', sulla stessa tabella ...

# re: Un motivo in più per usare i Guid come chiavi primarie

Capisco il problema ma non condivido la soluzione.
Usare un GUID significa usare una chiave che occupa 4 volte tanto lo spazio di un INT. Spesso la primary key è usata anche come indice clustered (visto che è il default) e ciò ha come conseguenza quella di propagare il GUID in tutti gli indici secondari. L'efficienza cala e la cosa è sensibile in database un po' grandi. E sicuramente il problema dei conflitti non ce l'hai in un database piccolo.
Quando ho avuto altri problemi sull'uso di IDENTITY, la soluzione è stata generare la chiave all'esterno piuttosto che farla generare a SQL Server...

Marco

# re: Un motivo in più per usare i Guid come chiavi primarie

Macché polemiche, siamo tutti maggiorenni, quindi basta leggere (e di materiale ce n'è fin troppo) e decidere se morire di int a 64 bit o di guid a 128 bit.
Considerato poi che sulla "cloud" i db relazionali non esistono e i guid sono un must, eccotene un altro di buon motivo.

Purtroppo la contemporaneità che credi che sia così improbabile io l'ho già vista. Prova ad usare @@Identity al posto di @@scope_identity e ti accorgi presto di avere in mano un int che non è il tuo, anche in un ambiente non enterprise.

# re: Un motivo in più per usare i Guid come chiavi primarie

Marco, non sto dicendo che sia da usare solo il Guid, ma sinceramente preferisco sprecare un po' di spazio piuttosto che complicare la logica di gestione.
Oggi i tera non costano, mentre lo sviluppatore (e i suoi errori) si.
Il Guid rende tutto terribilmente più semplice e se non ci sono casi particolari è decisamente più conveniente.
Mettiamola così. Se scopri che ci sono dei problemi di performance passare da un Guid ad un int è indolore. Il contrario non è altrettanto banale.
In pratica se parti da un int stai facendo premature optimization.

# re: Un motivo in più per usare i Guid come chiavi primarie

Non mi convinci :)
Su un Data Mart, non dobbiamo neanche discuterne perché la penalizzazione del GUID è troppo forte.
Su un database "normale", prima di usare un int64 devi avere più di due miliardi di righe in una tabella, il che limita molto i casi in cui ciò sia necessario. Il problema non è lo spazio su disco, quanto l'efficienza nell'uso dell'I/O e nell'uso della cache. La chiave che usi su un indice clustered in SQL Server è un fattore leva che agisce su tutti gli indici, quindi stai esercitando una leva su tutta la dimensione della tabella.
Non metto in dubbio che ci siano scenari in cui l'uso del GUID sia consigliabile (e quando serve va usato). Ma l'uso generalizzato del GUID come chiave primaria di qualsiasi tabella (occhio, ho detto tabella, non ho detto entità) lo vedo pericoloso, così come è pericoloso usare indiscriminatamente INT IDENTITY anche quando esiste una chiave primaria naturale nell'entità.
Quello che dunque non condivido è il suggerimento di usare indiscriminatamente i GUID per qualsiasi tabella. Io non dico di usare sempre INT IDENTITY, io dico di pensare a quello che si sta facendo valutandone le conseguenze. Per esempio, un GUID, prestazionalmente parlando, se usato come indice clustered dà luogo a effetti di frammentazione e page split che vanno al di là del semplice problema dell'occupazione di spazio, tanto per fare un esempio. E questi effetti sono tanto più significativi quanto più è grande la tabella.

Marco

# re: Un motivo in più per usare i Guid come chiavi primarie

@Marco
Tu dici: "Quello che dunque non condivido è il suggerimento di usare indiscriminatamente i GUID per qualsiasi tabella"
Neppure io! Il titolo del post è "Un motivo in più ...". E nel commento precedente dico "non sto dicendo che sia da usare solo il Guid"".

Certamente preferisco l'uso di un guid prima di un int, ma le scelte alla cieca non fanno per me :)
Più volte mi è capitato di vedere il cliente che accetta di vedere se sul db ci sono problemi macroscopici ma rinuncia a spendere in ottimizzazioni preferendo spendere in hardware o investire nello sviluppo di codice che risparmi gli accessi su db.
Tu mi potrai trovare dozzine di casi in cui il Guid ti penalizza. Io te ne trovo altrettanti in cui posso minimizzare il problema nell'application server. Alla fine ci mettiamo a discutere di architettura e non se ne esce più.
Ripeto: non sarà una soluzione universale, ma IMHO è certamente preferibile se non in casi particolari.
Poi ciascuno tragga le sue conclusioni dai nostri commenti :)

# re: Un motivo in più per usare i Guid come chiavi primarie

Io sto usando (dopo un travagliato processo decisionale) i GUID proposti nell'articolo su informit, con le ultime cifre generate in modo sequenziale. Mi sembra un buon compromesso. D'altra parte, per generare le chiavi nella logica applicativa, non vedo molte alternative... Una generazione sequenziale pone sempre problemi di concorrenza. Si può poi disquisire se serva o meno avere le chiavi prima che i dati vengano persistiti sul database. Secondo me, in scenari disconnessi, può fare comodo. Dipende, in ogni caso, dalla situazione.

# re: Un motivo in più per usare i Guid come chiavi primarie

Mah, lasciamo perdere tanto non serve a niente.
Hai ragione tu, giudicherà chi legge... e spero che chi deve leggere finalmente inizi a farlo!

# re: Un motivo in più per usare i Guid come chiavi primarie

@Davide. Nel mio commento non ti ho fatto dire nulla. Cerca di fare altrettanto.
Questo post non è una discussione Guid vs int. Su UGI e in tanti altri posti queste discussioni sono già state fatte ampiamente e chiunque può farsi una opinione.
E poi non capisco il termine 'paura'. Ho scritto che leggere il bug feedback è istruttivo e ho sottolineato in bold, underline e italic che avviene solo in un caso molto particolare.
Il terrorismo lo state facendo voi.

Aria fritta. Esatto. Io ho postato e l'unico argomento tecnico è quello di Marco. Il resto è proprio aria fritta.
La rabbia c'è ed e chiaro secondo il gergo internet. Il tutto maiuscolo significa urlare e qui la voce l'avete alzata in due. Per non parlare del modo...

# re: Un motivo in più per usare i Guid come chiavi primarie

"Io ho postato e l'unico argomento tecnico è quello di Marco"
Se sostieni che il mio post non è tecnico, francamente è inutile stare a discutere, visto che si nega l'evidenza. Neghi pure quello che hai scritto nero su bianco, visto che il tuo post cita testualmente "vivi più tranquillo e usa un bel Guid se non in casi tutti da valutare", mentre ora dici che il bug "avviene solo in un caso molto particolare".

Bah, inutile continuare a discutere con chi non vuol capire.

Il giorno che farai un post tecnico, con delle dimostrazioni a carico delle tue affermazioni si potrà tornare a discutere, fino a quel momento si perde solo tempo.

# re: Un motivo in più per usare i Guid come chiavi primarie

È certamente meglio lasciare che ciascuno giudichi leggendo perché le cose sono palesi nei vari commenti, come ad esempio lo scrivere tutto maiuscolo.

Quanto all'esperienza e alla responsabilità non ho proprio nulla da temere perché sono stati i feedback dei clienti a dirmelo.
Fin dal primo commento a Marco ho chiarito, se ce ne fosse bisogno, che non c'era alcuna 'parola defintiva' sull'uso di int o guid. Tu invece ti sei scatenato in una raffica di post a senso unico. La scelta definitiva dipende sempre dal contesto del progetto e personalmente prediligo i guid ma non ho mai detto di usare solo questi. Fin'ora i risultati mi hanno dato ragione.

Quanto ai confronti, le gare non mi toccano proprio. Io non metto in dubbio la tua professionalità, ma ti interessa tanto la mia senza neppure sapere cosa faccio.

Per quanto riguarda il discorso MVP, il premio è per quanto si è detto e fatto in *passato*, dopo valutazione delle persone dei team interessati. Il fatto di fregiarsi di un prestigioso titolo come questo, è come un curriculum. Di sedicente quindi non c'è nulla e non sono io a dirlo.

Infine per l'ultimo commento non è certamente indispensabile l'uso del Guid ma è certamente preferibile. La valutazione dipende dal progetto ma è la *mia* scelta numero 1. E i fattori decisionali non sono solo la quantità e forma dei dati.
Non sei sicuramente daccordo ma per dirlo c'è modo e modo.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Raffaeu. Lo scopo del post non era affatto di disquisire sui pro e contro dei guid vs int ma di suggerire la lettura di quel feedback che la ritengo molto istruttiva a prescindere dal bug di per se.
La discussione sui pro e contro è già stata fatta sul forum di UGI in passato con un thread più che esaustivo in cui un po' tutti hanno dato il proprio contributo e con toni pacati.
Altre risorse/articoli ci sono in giro compresi i guid sequenziali e altre ottimizzazioni nell'uso dei guid presenti a partire da SQL 2005.

Detto questo, io non userei un codice_ordine per esempio perché non puoi sapere a priori come evolverà l'applicazione. Una cosa che mi è capitata di frequente è di vedere chiavi primarie stile "ALFKI" (degli esempi di sql server tanto per intenderci) che, per motivi di evoluzione dell'applicazione, col tempo non erano più univoche.
Avere chavi primarie svincolate dalla logica dei dati IMHO è un requisito fondamentale per poter evolvere bene l'applicazione.

L'int ha il vantaggio di essre un ottimo candidato per le key di un dictionary e genericamente in hashtable. Questo lo rendono estremamente performante nella ricerca (ho postato su differenze di dictionary e collection tempo fa qui nel mio blog).
Inoltre l'int ha il vantaggio di essere della dimensione di un registro della CPU e quindi l'algoritmo esegue molto meno I/O in memoria.
Fortunatamente le cache L2 (circa 1 ordine di grandezza più veloce della RAM) sono molto grosse e un algoritmo ben scritto può soffrire poco se qualcosa non riesce a stare nei registri che sono ovviamente pochi.

Il Guid ha il vantaggio di essere globalmente sempre univoco. In pratica negli scenari disconnessi hai sempre la certezza di non collidere mai con quanto è già presente sul DB. Ci sono dozzine di problematiche di cui tenere conto nella gestione di inserimento di un dato nel DB e l'uso del guid risolve in modo semplice buona parte di questi problemi.
Essendo un numero a 128 bit il guid non sta dentro un registro e quindi richiede maggiore I/O, oltre a fenomeni di aumentata frammentazione e page split come già detto negli altri commenti.
In certi scenari dove è possibile prevedere una estendibilità, l'uso di un Guid può essere una buona assicurazione. Mi è capitato di scrivere una estensione a TFS ma purtroppo c'erano degli int sul database che ci hanno obbligato a realizzare una logica molto più complessa. Ripeto: dipende dallo scenario.

Ovviamente questo breve riassunto non basta a decidere. Dipende dal tipo di applicazione e dal tipo di architettura utilizzata nell'applicazione. Per alcuni problemi relativi alle performance si può migliorare con una cache sull'application server, ma i fattori decisionali sono diversi.

# re: Un motivo in più per usare i Guid come chiavi primarie

Intervengo per dire un paio di cose, putroppo brevemente, ma si tratta di pur sempre di un commento.

La prima, voglio tranquillzare Silvano che nessuno prende nulla come oro colato, specialmente se lo trova letto su un blog... qualche anticorpo ormai ce lo siamo fatti tutti, solo uno stolto può prendere una riga scritta in un qualsiasi post e usarla come proprio credo. Persino le parole della Bibba debbono essere interpretate, figuriamoci quelle trovate sul web. Talebano è quello che rinuncia a ragionare sulle cose scritte, non quello che le scrive.

La seconda, tecnica, si riassume in una frase del post precdente "Avere chavi primarie svincolate dalla logica dei dati IMHO è un requisito fondamentale per poter evolvere bene l'applicazione." Che io interpreto, scusadomi con Raf se non colgo l'interpretazione originale, nel domain model non dovrebbero esserci riferimenti vincolanti alle primary key. Cioè le primary key non dovrebbero essere usate nel model per gestire la logica relazionale. Qalsiasi sia il meccanismo usato nel model esso dovrebbe essere "mappato" sulle effettive chiavi di relazioni solo all'ultimo momento, durante la persistenza del dato nel db.

Mi fermo qua, ringraziando Raf e gli altri per l'interessante post.

# re: Un motivo in più per usare i Guid come chiavi primarie

"Il Guid ha il vantaggio di essere globalmente sempre univoco. In pratica negli scenari disconnessi hai sempre la certezza di non collidere mai con quanto è già presente sul DB. Ci sono dozzine di problematiche di cui tenere conto nella gestione di inserimento di un dato nel DB e l'uso del guid risolve in modo semplice buona parte di questi problemi."
Benchè ciò sia vero - anche se sarebbe bello fare esempi di queste tematiche e non stare sul vago, altrimenti si potrebbero creare più dubbi nel lettore che quanti se ne mirino a risolvere - il post nasce parlando di GUID sulle PK.....ed il problema è tutto qui. Un GUID se serve può traquillamente essere usato come Alternate Key, in modo da non appesantire tutte le FK che si riferiscono alle PK e limitare al massimo il problema di frammentazione dei dati e di ingigantimento degli indici.
Teniamo ben presente questa cosa, perchè il punto della discordia è tutto li...non certo sull'utilità o meno di usare GUID in altri casi. Quella è una questione architetturale che dipende strettamente dalle necessità funzionali e non è quindi possibile dibatterla solamente da un punto di vista tecnico (se non parlando più in generale, come ho fatto nel mio post)

PS
GUID si scrive maiuscolo, non sto urlando :-) ROTFL (pure questo non è urlo, neh!...è che si scrive cosi!) :-) :-) :-)

# re: Un motivo in più per usare i Guid come chiavi primarie

"Il che conduce ha prendere "
Arght! :-) Mi flagello da solo :-).....managgia alla voglia di scrivere in fretta! :-)

# re: Un motivo in più per usare i Guid come chiavi primarie

Non entro nella questione tecnica, credo si sia già detto detto tutto. Nonostante la mia diretta esperienza con i GUID in un applicativo enterprise, non voglio aggiungere altra carne al fuoco. Anche perché, ripeto, si è già detto tutto e la mia (dis)avventura con i GUID è già contenuta nel bellissimo articolo di Davide. Entro invece nel merito della forma dei contenuti, soprattutto dei commenti di Silvano che IMHO è stato molto maleducato nell'esposizione. Silvano cerca di avere più rispetto per le persone che non la pensano come te. Altrimenti passi solo da cafone e non da esperto.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Alessandro,
pur essendo completamente ignorante e piuttosto refrattario al termine "domain model" :) riconosco il concetto da te espresso perchè si mappa praticamente 100% con quello di "surrogate key" (al contrario delle "natural key") che vive da almeno 30 e passa anni nel mondo dei database server.
Non è nemmeno nuova la tecnica, classica nel mondo della programmazione "disconnessa" del layer di accesso ai dati, di utilizzare delle chiavi temporanee (tipicamente interi, autoincrementali e negativi) per la gestione delle relazioni in strutture dati (tipo master-detail) non ancora persistite nel database (ad esempio con i "damn' evil" DataSet :) che poi venivano sostituite dai valori generati server-side solo dopo aver eseguito l'inserimento nelle tabelle.
Questo tipo di approccio è sempre stato usato in tutti quei casi dove non era necessario conoscere a priori il valore della chiave logica effettiva dell'entità (es. id ordine), ma era comunuque importante conoscere quel valore per svolgere attività successive come l'inserimento di altre entità ad esso legate in altre tabelle. In questo scenario l'uso di un GUID non avrebbe di per se molto senso.
Siamo tutti d'accordo che "ALFKI" non sia la miglior candidata come primary key, ma se invece di dare una occhiata al vecchio Northwind si guarda anche solo AdventureWorks (che non è perfetto ma dove si trovano già diversi esempi interessanti anche tenendo conto il DW costruito di conseguenza) secondo me si può notare come l'approccio basato su chiavi naturali e surrogate può coprire la maggioranza degli scenari.
Poi ci sono anche tutti gli altri casi in cui è necessario conoscere a priori il valore della chiave di un record (oppure ne si è anche solo convinti...) oppure altri casi quali il mitco "numero fattura", ma qui entriamo in un altro campo.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Silvano: una certa esperienzucola ce l'ho anche io e anche io ho avuto il piacere di avere come maestro Antonio Sponza. So benssimo a cosa ti riferisci nei tuoi commenti e non trovi certo in me in fan sfegatato del Guid, anche se non mi piace che vengano demonizzate tout-court soluzioni che ne fanno uso, tutto qua: se come te ho trovato gente che vede il guid come manna dal cielo ho anche trovato gente che lo vede come il fumo negli occhi.
Hai indovinato, in effetti tendo ad usare il Guid solo dove serve e come surrogate key, come la definisci tu, ma non voglio farne una regola: in fondo il Guid è solo un datatype a 128 bit. Per chiuderla con una battuta, quello che ammazza non è la pistola, ma la mano che preme il grilletto.

# re: Un motivo in più per usare i Guid come chiavi primarie

Yup, concordo! :)
Mi sembra di aver già scritto da qualche parte che dopo essermi andato a vedere un pò di codice su come funzionano le repliche apprezzo molto l'uso dei GUID in scenari di quel genere. Così come in applicazioni online-offline o che consolidano dati da sorgenti diverse sono altri scenari interessanti. Anche se tipicamente i GUID vengono usati come colonna di "servizio" per gestire la riconciliazione dei dati distribuiti più che come chiave vera e propria.
Cmq, sul grilletto non si può non essere d'accordo :););)

# re: Un motivo in più per usare i Guid come chiavi primarie

"I Page split sai bene che possono anche accadere con PK di tipo int. Non puoi liquidare il problema ai solo fatto dei guid "
Si lo so bene, infatti ne nei commenti nè nel post ho mai parlato di page split, controlla bene :-)
La frammentazione non è solamente dovuta ai page split. Essi sicuramente ne contribuiscono alla formazione ma non sono il problema maggiore nel caso dell'utilizzo di un GUID non sequenziale, in quanto i dati sono già dispersi per il fatto che il GUID è un valore randomico, ed il page split influsce in modo minore a disperdere ulteriormente i dati.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Davide. Non stavo collegando frammentazione a page split. Volevo solo che fosse chiaro a chi legge che page split ci sono comunque e vanno valutati a prescindere da guid o int.
Con i sequential guid (che è sempre stato possibile usarli, anche con SQL2000) la randomicità non c'è. Una parte del guid è il MAC address e quindi è costante, il resto è un valore in funzione del tempo e perciò progressivo.

# re: Un motivo in più per usare i Guid come chiavi primarie

Mah, saranno anche conti difficili da fare ma se faccio Start->Run->Calc e subito dopo moltiplico 20M * 16 byte ottengo 305.18Mb, e anche senza considerare l'overhead dei metadati a livello di singola riga in una tabella, la frammentazione dei record nella pagina e altre cose di poco conto, con meno di quei 305Mb di certo non ci stò... non c'è bisogno di andare a cercare articoli su Internet per fare un calcolo come questo.
Se poi non sono sicuro e voglio controllare quanto spazio SQL Server ha allocato per quei dati posso sempre usare:

select * from sys.dm_db_partition_stats where object_id = OBJECT_ID('NomeTabella')

e da qui alla colonna in_row_data_page_count avere una indicazione di quante pagine da 8K sono state usate per contenere le righe e gli indici di una determinata tabella.
Detto questo, continuo a non capire questo riferimento costante alla cache L2 del processore, temo che con il nostro discorso non c'entri proprio nulla. Infatti SQL Server per poter fare qualsiasi tipo di operazione sui dati ha bisogno di caricare le suddette pagine dal disco (se già non sono state caricate in precedenza) all'interno dei propri buffer dati, che non risiedono nella cache del processore ma in RAM. Solo dopo, quando verranno fatte operazioni sui dati, quelle informazioni passeranno nella cache.

A tal proposito, nel caso tu volessi vedere la quantità di pagine caricate nei buffer di memoria, magari filtrando per oggetto o per database, puoi utilizzare alcune DMV con una query come questa:

select b.database_id, db=db_name(b.database_id)
,p.object_id
,object_name(p.object_id) as objname
,p.index_id
,buffer_count=count(*)
from sys.allocation_units a,
sys.dm_os_buffer_descriptors b,
sys.partitions p
where a.allocation_unit_id = b.allocation_unit_id
and a.container_id = p.hobt_id and b.database_id = DB_ID('NomeDB') and p.object_id = OBJECT_ID('NomeTabella')
group by b.database_id,p.object_id, p.index_id
order by buffer_count desc

Se parliamo di performance, in una applicazione OLTP che genera I/O tipicamente random (e non sequenziali come l'OLAP/Reporting) una tra le caratteristiche hw dei dischi più importante sono i tempi di accesso, che negli ultimi 10 anni non sono cambiati significativamente perchè legati direttamente alla velocità di rotazione dei piattelli dei dischi stessi. Essendo già in produzione 10 anni fa dei dischi con ottime performance (15K rpm) l'hardware non aiuta a mettere delle pezze alle applicazioni scritte male. Una riprova sono i numeri dei benchmark TPC/C che sono aumentati in modo assolutamente non lineare con il progredire delle componenti hw ma che hanno raggiunto valori superiori solo creando sistemi "monstre".

Come ho già scritto diverse volte, il problema qui non sono le performance assolute che sono evidentemente poco significative, il problema è che questo genere di scelte ha impatti importanti anche in casi molto concreti, con clienti normali, con numeri non stratosferici di dati e di utenti concorrenti, e che mai come in un database server risparmiare "il grammo" è importante, perchè le risorse non sono infinite e soprattutto sono condivise.

# re: Un motivo in più per usare i Guid come chiavi primarie

"Con i sequential guid (che è sempre stato possibile usarli, anche con SQL2000)": si ma solo se te li generi a mano; la funzione NEWSEQUENTIALID è stata introdotta in SQL 2005.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Silvano. L'errore su quella cifra è palese. Il perché dei conti è semplice: non posso assumere che lo storage del guid sia as-is. Per cui una controprova era necessaria perché non ci fosse ulteriore overhead non dipendente dallo storage puro del solo guid.

Il discorso I/O dipende dagli scenari perché per determinare il set di dati da restituire nel resultset, le key possono essere mantenute in memoria e non credo che vengano rilette tutte le pagine del db da disco ogni volta.
Se restituisci grossi set di dati o esegui conti sulle righe, etc. etc. dovranno essere rilette le pagine filtrate da disco, quindi I/O discretamente grandi. Ma questo tipo di operazioni non sono comuni a tutte le applicazioni.
Se restituisci pochi dati alla volta, cosa comune nelle applicazioni con accesso di tipo disconnesso, le pagine lette da disco dovrebbero essere decisamente poche.
L'impatto dell'accesso alla RAM c'è sempre per costruire il set filtrato.

Io non metto in dubbio che in moti scenari l'impatto dell'I/O sia molto significativo ma dipende dal tipo di applicazione e dalla sua architettura. A volte puoi, a volte no e quindi, in quei casi, ti tocca limare il grammo.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Davide. Si certo. In origine la funzione uuidcreate creava solo guid sequenziali. Poi per motivi di privacy è stata 'randomizzata' e la versione originale esposta per compatibilità nella uuidcreatesequential.
Ricordo Don Box che, per ovviare ai problemi di privacy prima di questa nuova api, aveva esposto un servizio di creazione di guid sul suo website.
Quindi la creazione sequenziale è in realtà quella "vera" ed è sempre stata usabile anche se in sql 2000 doveva essere fatto a mano (ma con poche righe di extended sp).

# re: Un motivo in più per usare i Guid come chiavi primarie

"Il perché dei conti è semplice: non posso assumere che lo storage del guid sia as-is. Per cui una controprova era necessaria perché non ci fosse ulteriore overhead non dipendente dallo storage puro del solo guid."

"Il discorso I/O dipende dagli scenari perché per determinare il set di dati da restituire nel resultset, le key possono essere mantenute in memoria e non credo che vengano rilette tutte le pagine del db da disco ogni volta."

Illuminante!! Fosse stato cosi' lampante dall'inizio che non era chiaro di cosa si stava parlando la discussione sarebbe stata piu' profiqua per chi ha letto o leggera' in futuro. Comunque qualcosa porteranno a casa anche cosi'.

Approfitto per fare gli auguri di buon anno a tutti e a presto.
Passo e chiudo.

# re: Un motivo in più per usare i Guid come chiavi primarie

@Silvano. Non so a cosa alludi, ma io mi sono solo limitato a rispondere alle questioni che sono state sollevate.
Ripeto che il post non aveva la velleità di dare alcuna sentenza su guid o int. Poi ben vengano le discussioni pacifiche in cui ciascuno dice la sua.
Con questo non pretendo di convincere nessuno ma spero solo che siano spunti per riflettere, tutto qui. E forse questo è l'unico punto su cui siamo daccordo.
Auguri di buon anno a te e a tutti quanti.

# re: Un motivo in più per usare i Guid come chiavi primarie

Interessante questo articolo, grazie per le informazioni e buone feste a tutti