J'utilise toujours des clés primaire avec un type GUID pour toutes mes tables en base de données. Il y a beaucoup d'avantages à faire ça :
- On peut generer un ID avant l'insert
- Si on traite coté client il y a un obfsucation par défaut même si on utilise des GUID sequentiels Guid.CreateVersion7(), plus difficile pour le scraping par exemple.
- Réplication de base de données faclitée
- Compatible avec beaucoup de base de données (Sql Server, PosgreSql, SQLite, ...)
Inconvenients :
- Fragmentation de l'index, ne pas mettre d'index cluster sur la PK si c'est vraiment des GUID aléatoires, mais la V7 corrige ce désavantage.
Mais il y a des cas de figure ou il faut récuperer des valeurs dans des tables existantes qui elles, avaient une clé primaire en int.
Pour garder la compatibilité et éviter d'avoir une colonne de "compatibilité" lors d'une migration, il est possible de convertir un int en GUID et bien sur l'inverse , voici une methode d'extension qui permet de réaliser cette opération :
public static class GuidExtensions
{
public static Guid ToGuid(this int value)
{
byte[] array = new byte[16];
byte[] bytes = BitConverter.GetBytes(value);
bytes.CopyTo(array, 0);
return new Guid(array);
}
public static int ToInt32(this Guid guid)
{
byte[] bytes = guid.ToByteArray();
return BitConverter.ToInt32(bytes, 0);
}
}
Par exemple :
var intToGuid = 4810.ToGuid();
Console.WriteLine(intToGuid);
var guidToInt = new Guid("000012ca-0000-0000-0000-000000000000").ToInt32();
Console.WriteLine(guidToInt);
var x = new Guid("40ceee13-cc3e-4111-b3cc-c73837fbc4c4").ToInt32();
Console.WriteLine(x);
Résultat :
000012ca-0000-0000-0000-000000000000
4810
1087303187