Le site correct La chose à faire ici est de le stocker comme uniqueidentifier
- ce qui est ensuite entièrement indexable, etc. dans la base de données. La meilleure option suivante serait un binary(16)
colonne : les GUID standard ont une longueur d'exactement 16 octets.
Si vous devez le stocker sous forme de chaîne, la longueur dépend de la façon dont vous choisissez de l'encoder. En hexadécimal (alias codage en base 16) sans trait d'union, il y aurait 32 caractères (deux chiffres hexadécimaux par octet), soit char(32)
.
Cependant, vous pourriez veulent pour stocker les traits d'union. Si vous manquez d'espace, mais que votre base de données ne prend pas en charge les blobs / guids de manière native, vous pouvez utiliser les éléments suivants Base64 et supprimez l'encodage ==
suffixe de remplissage ; cela vous donne 22 caractères, donc char(22)
. Il n'est pas nécessaire d'utiliser l'Unicode, ni de disposer d'une longueur variable. nvarchar(max)
serait un mauvais choix, par exemple.
1 votes
Note :
Guid.NewGuid
n'a pas de "longueur de chaîne" implicite ; tout dépend du format utilisé dans le fichier ToString (L'option sans argumentToString
utilise le formatage "D"). Je préfère le format "B" car il est plus facile de "voir qu'il s'agit d'un GUID", mais ce n'est qu'une question de familiarité et de convention.9 votes
Pourquoi ne pas simplement l'enregistrer comme un identifiant unique de 16 octets ?