Discussion :

[Marty000]

Bonjour,

dans le cadre d'un de nos projets sous SQL Server 2014 nous disposons de deux tables qui sont synchronisées entre une application web et des smartphones sous Android (elles sont donc présentes sur tous les mobiles). Dans notre base ces deux tables possèdent des identifiants uniques de type "entier" en tant que clé primaire, mais nous disposons également d'une colonne GUID unique qui permet d'avoir un identifiant unique qui va "suivre" la donnée dès sa création sur les portables.

Ainsi notre table A :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
A_ID int
A_guid nvarchar(50)

Et notre deuxième table DetailA :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
detailA_ID int
detailA_guid nvarchar(50)
A_guid nvarchar(50) (sur mobile exclusivement)

Les colonnes GUID sont utilisées dans les applications mobiles et au moment de la synchronisation sur le serveur SQL, les données de "detailA" vont aller chercher l'ID de SQL Server correspondant à son "A_guid" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select A_ID from A where A_guid = detailA.A_guid

Grâce à ce système toutes nos données sont correctement liées les unes aux autres via les identifiants SQL Server. Bien sûr tout fonctionne tant que les données sont peu nombreuses. Mais maintenant nous avons plusieurs millions d'informations dans nos tables et les recherches sur les colonnes "GUID" commencent à prendre du temps (quelques secondes mais nous savons que cela va augmenter), je cherche donc un moyen d'accélérer le processus. Toutes nos colonnes GUID sont au format :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ID_DU_SMARTPHONE-YYYMMDD-[Fonction NEWID() de SQL]

Je pensais que grâce à ce format nous pourrions éventuellement appliquer un index mais ce n'est pas très efficace. J'ai pensé à changer le format pour qu'ils correspondent à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ID_DU_SMARTPHONE-YYYMMDD_HIS

Mais je ne sais pas si nous gagnerons en rapidité.

Je suis preneur de toute idée.

Merci.

[SQLpro]

Il suffit d'indexer correctement et notamment avec un index UNIQUE !

A +

[Michel.Priori]

C'est pour répondre aux cahier des charges comme le votre que le type uniqueidentifier a été implémenté.
Ce type est dédié au stockage des GUID.

Si vous pouvez gagner en stockage sans compromettre l'objectif d'unicité global c'est une piste à suivre.

Rappels :
uniqueidentifier occupe 16 octets (taille fixe)
les types "fixes" sont plus performants que les types "variables"

La fonction newid() présente l'inconvénient d'être purement aléatoire.
La fonction newsequentialid() a l'avantage de rester aléatoire tout en ajoutant la contrainte de "valeur supérieure à la précédente". Ceci a le bon ton d'éviter une fragmentation délirante des index.
https://docs.microsoft.com/fr-fr/sql...ql-server-2017

[Marty000]

Je vous remercie de vos retours.

Je vais changer tout ça.

[SQLpro]

...
La fonction newid() présente l'inconvénient d'être purement aléatoire.
La fonction newsequentialid() a l'avantage de rester aléatoire tout en ajoutant la contrainte de "valeur supérieure à la précédente". Ceci a le bon ton d'éviter une fragmentation délirante des index.
https://docs.microsoft.com/fr-fr/sql...ql-server-2017

Ce n'est pas non plus la panacée car le tri des GUID n'est pas linéaire comme l'est le NESEQUENTIALID()….

A +