pour des raisons de merge entre BD, j'ai decidé d'utiliser uniqueidentifier
comme clé primaire dans certains tables, il me reste a definir si je dois
creer ses clés come PK clustered index ou PK NONclustred index, certaines
documentations disent que pour augmenter les performances (dans le cas de
Clustred Index) il faut utiliser des colonnes incrementales a fin que
l'insert soit performant (pas besoin de reorganisation a chaque insert car
toutes les records sont inserés a la fin), d'autres documentaion disent le
contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me repondent
et me suggerent quelle solution je dois opter pour mes uniqueidentifier
colonnes : Clustred ou NONclustred
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
uniqueidentifier => 16 octets soit 128 bits integer => 4 octets soit 32 bits
les processeurs actuels (pentium et coetera) sont taillé pour du 32 bits et optimisé pour cela. Si tu utilise de l'uniqueidentifier il te faudra 4 fois plus de cycles processeur pour faire la comparaison (jointure) qu'avec un entier 32 bits.
As ton avis, quelle est la clef la plus performante ???
A lire sur le sujet : http://sqlpro.developpez.com/OptimSQL/SQL_optim.html
A +
daniel a écrit:
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser uniqueidentifier comme clé primaire dans certains tables, il me reste a definir si je dois creer ses clés come PK clustered index ou PK NONclustred index, certaines documentations disent que pour augmenter les performances (dans le cas de Clustred Index) il faut utiliser des colonnes incrementales a fin que l'insert soit performant (pas besoin de reorganisation a chaque insert car toutes les records sont inserés a la fin), d'autres documentaion disent le contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me repondent et me suggerent quelle solution je dois opter pour mes uniqueidentifier colonnes : Clustred ou NONclustred
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
uniqueidentifier => 16 octets soit 128 bits
integer => 4 octets soit 32 bits
les processeurs actuels (pentium et coetera) sont taillé pour du 32 bits
et optimisé pour cela. Si tu utilise de l'uniqueidentifier il te faudra
4 fois plus de cycles processeur pour faire la comparaison (jointure)
qu'avec un entier 32 bits.
As ton avis, quelle est la clef la plus performante ???
A lire sur le sujet :
http://sqlpro.developpez.com/OptimSQL/SQL_optim.html
A +
daniel a écrit:
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser uniqueidentifier
comme clé primaire dans certains tables, il me reste a definir si je dois
creer ses clés come PK clustered index ou PK NONclustred index, certaines
documentations disent que pour augmenter les performances (dans le cas de
Clustred Index) il faut utiliser des colonnes incrementales a fin que
l'insert soit performant (pas besoin de reorganisation a chaque insert car
toutes les records sont inserés a la fin), d'autres documentaion disent le
contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me repondent
et me suggerent quelle solution je dois opter pour mes uniqueidentifier
colonnes : Clustred ou NONclustred
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
****************** mailto:brouardf@club-internet.fr ******************
uniqueidentifier => 16 octets soit 128 bits integer => 4 octets soit 32 bits
les processeurs actuels (pentium et coetera) sont taillé pour du 32 bits et optimisé pour cela. Si tu utilise de l'uniqueidentifier il te faudra 4 fois plus de cycles processeur pour faire la comparaison (jointure) qu'avec un entier 32 bits.
As ton avis, quelle est la clef la plus performante ???
A lire sur le sujet : http://sqlpro.developpez.com/OptimSQL/SQL_optim.html
A +
daniel a écrit:
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser uniqueidentifier comme clé primaire dans certains tables, il me reste a definir si je dois creer ses clés come PK clustered index ou PK NONclustred index, certaines documentations disent que pour augmenter les performances (dans le cas de Clustred Index) il faut utiliser des colonnes incrementales a fin que l'insert soit performant (pas besoin de reorganisation a chaque insert car toutes les records sont inserés a la fin), d'autres documentaion disent le contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me repondent et me suggerent quelle solution je dois opter pour mes uniqueidentifier colonnes : Clustred ou NONclustred
-- Frédéric BROUARD - expert SQL, spécialiste : SQL Server / Delphi / web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ****************** mailto: ******************
Med Bouchenafa[MVP]
Il y a un très bon article actualisé sur le sujet ici : http://www.sql-server-performance.com/clustered_indexes.asp
On pourra le discuter si nécessaire. Pour ma part, je fais mienne cette règle : Les données ne font l'objet que d'un seul "INSERT" alors qu'elles font l'objet de plusieurs "SELECT"
-- Bien cordialement Med Bouchenafa TETRASET 75015 Paris "daniel" wrote in message news:
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser
uniqueidentifier
comme clé primaire dans certains tables, il me reste a definir si je dois creer ses clés come PK clustered index ou PK NONclustred index, certaines documentations disent que pour augmenter les performances (dans le cas de Clustred Index) il faut utiliser des colonnes incrementales a fin que l'insert soit performant (pas besoin de reorganisation a chaque insert car toutes les records sont inserés a la fin), d'autres documentaion disent le contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me
repondent
et me suggerent quelle solution je dois opter pour mes uniqueidentifier colonnes : Clustred ou NONclustred
Il y a un très bon article actualisé sur le sujet ici :
http://www.sql-server-performance.com/clustered_indexes.asp
On pourra le discuter si nécessaire.
Pour ma part, je fais mienne cette règle :
Les données ne font l'objet que d'un seul "INSERT" alors qu'elles font
l'objet de plusieurs "SELECT"
--
Bien cordialement
Med Bouchenafa
TETRASET
75015 Paris
"daniel" <dansauve2003@yahoo.com> wrote in message
news:eKObR8klDHA.3316@tk2msftngp13.phx.gbl...
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser
uniqueidentifier
comme clé primaire dans certains tables, il me reste a definir si je dois
creer ses clés come PK clustered index ou PK NONclustred index, certaines
documentations disent que pour augmenter les performances (dans le cas de
Clustred Index) il faut utiliser des colonnes incrementales a fin que
l'insert soit performant (pas besoin de reorganisation a chaque insert car
toutes les records sont inserés a la fin), d'autres documentaion disent le
contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me
repondent
et me suggerent quelle solution je dois opter pour mes uniqueidentifier
colonnes : Clustred ou NONclustred
Il y a un très bon article actualisé sur le sujet ici : http://www.sql-server-performance.com/clustered_indexes.asp
On pourra le discuter si nécessaire. Pour ma part, je fais mienne cette règle : Les données ne font l'objet que d'un seul "INSERT" alors qu'elles font l'objet de plusieurs "SELECT"
-- Bien cordialement Med Bouchenafa TETRASET 75015 Paris "daniel" wrote in message news:
cher DBA et utilsateurs de Sqlserver salut
pour des raisons de merge entre BD, j'ai decidé d'utiliser
uniqueidentifier
comme clé primaire dans certains tables, il me reste a definir si je dois creer ses clés come PK clustered index ou PK NONclustred index, certaines documentations disent que pour augmenter les performances (dans le cas de Clustred Index) il faut utiliser des colonnes incrementales a fin que l'insert soit performant (pas besoin de reorganisation a chaque insert car toutes les records sont inserés a la fin), d'autres documentaion disent le contraire et parlent du probleme de "Hotspot"
j'aimerai bien que des GuRUs de performances et d'optimisations me
repondent
et me suggerent quelle solution je dois opter pour mes uniqueidentifier colonnes : Clustred ou NONclustred
