Une petite question : je dois créer des tables dans une base, et
j'envisage de créer pour l'une d'entre elles une clef primaire de type
alphabétique (5 caractères qui servent à identifier des objets
différents). Est-ce raisonnable, ou faut-il préférer des IDentifiants
au format INT ?
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 - SQLpro
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins rapide qu'un entier du fait du jeu de caractères et de la collation. Avec 5 caractères en CHAR il faut 5 octets. Donc la comparaison sera 8 fois moins rapide. Si VARCHAR(5) ce sera pire encore car il faut traiter la longueur réelle, soit 16 fois moins rapide. Enfin si la clef est un NCHAR elle occupe donc 10 octets, soit 24 fois moins rapide et si c'est un NVARCHAR, compte 48 fois moins rapide. Cela peut être encore pire, ou mieux, suivant l'optimisateur et la façon dont sont stocké les clef (fragmentation des pages notamment).
En comparaison un entier ne nécessite aucune transformation avant comparaison, à condition qu'il soit de la longueur du mot du processeur. Ainsi un SMALLINT sera moins rapide qu'un INTEGER sur plateforme 32 bits !
a écrit:
Bonjour,
Une petite question : je dois créer des tables dans une base, et j'envisage de créer pour l'une d'entre elles une clef primaire de type alphabétique (5 caractères qui servent à identifier des objets différents). Est-ce raisonnable, ou faut-il préférer des IDentifiants au format INT ?
Merci de vos conseils !
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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 ************************ www.datasapiens.com *************************
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins rapide
qu'un entier du fait du jeu de caractères et de la collation. Avec 5 caractères
en CHAR il faut 5 octets. Donc la comparaison sera 8 fois moins rapide. Si
VARCHAR(5) ce sera pire encore car il faut traiter la longueur réelle, soit 16
fois moins rapide. Enfin si la clef est un NCHAR elle occupe donc 10 octets,
soit 24 fois moins rapide et si c'est un NVARCHAR, compte 48 fois moins rapide.
Cela peut être encore pire, ou mieux, suivant l'optimisateur et la façon dont
sont stocké les clef (fragmentation des pages notamment).
En comparaison un entier ne nécessite aucune transformation avant comparaison, à
condition qu'il soit de la longueur du mot du processeur. Ainsi un SMALLINT sera
moins rapide qu'un INTEGER sur plateforme 32 bits !
database@database.com a écrit:
Bonjour,
Une petite question : je dois créer des tables dans une base, et
j'envisage de créer pour l'une d'entre elles une clef primaire de type
alphabétique (5 caractères qui servent à identifier des objets
différents). Est-ce raisonnable, ou faut-il préférer des IDentifiants au
format INT ?
Merci de vos conseils !
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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
************************ www.datasapiens.com *************************
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins rapide qu'un entier du fait du jeu de caractères et de la collation. Avec 5 caractères en CHAR il faut 5 octets. Donc la comparaison sera 8 fois moins rapide. Si VARCHAR(5) ce sera pire encore car il faut traiter la longueur réelle, soit 16 fois moins rapide. Enfin si la clef est un NCHAR elle occupe donc 10 octets, soit 24 fois moins rapide et si c'est un NVARCHAR, compte 48 fois moins rapide. Cela peut être encore pire, ou mieux, suivant l'optimisateur et la façon dont sont stocké les clef (fragmentation des pages notamment).
En comparaison un entier ne nécessite aucune transformation avant comparaison, à condition qu'il soit de la longueur du mot du processeur. Ainsi un SMALLINT sera moins rapide qu'un INTEGER sur plateforme 32 bits !
a écrit:
Bonjour,
Une petite question : je dois créer des tables dans une base, et j'envisage de créer pour l'une d'entre elles une clef primaire de type alphabétique (5 caractères qui servent à identifier des objets différents). Est-ce raisonnable, ou faut-il préférer des IDentifiants au format INT ?
Merci de vos conseils !
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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 ************************ www.datasapiens.com *************************
John Mackerel
Fred BROUARD - SQLpro wrote:
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
[...]
un NVARCHAR, compte 48 fois moins rapide.
Ces chiffres sortent-ils de mesures réelles ?
Fred BROUARD - SQLpro wrote:
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
[...]
un NVARCHAR, compte 48 fois moins rapide.
Ces chiffres sortent-ils de mesures réelles ?
Fred BROUARD - SQLpro
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à encapsuler les jeux de caractères et collations et comment sont fait les optimisations.
On peut dire la chose suivante : entre le code binaire d'un caractère et son jeu de caractère il y a au moins une phase de code de plus que la lecture d'un binaire représentant un entier 32 bits. entre le code binaire d'un caractère et sa collation il y a au moins une phase de code de plus après traitement du jeu de caractères que la lecture d'un binaire représentant un entier 32 bits. le varchar possède lui aussi un traitement particulier supplémentaire car il faut d'abord le dimensionner. Un processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
John Mackerel a écrit:
Fred BROUARD - SQLpro wrote:
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
[...]
un NVARCHAR, compte 48 fois moins rapide.
Ces chiffres sortent-ils de mesures réelles ?
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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 ************************ www.datasapiens.com *************************
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à encapsuler
les jeux de caractères et collations et comment sont fait les optimisations.
On peut dire la chose suivante :
entre le code binaire d'un caractère et son jeu de caractère il y a au moins une
phase de code de plus que la lecture d'un binaire représentant un entier 32 bits.
entre le code binaire d'un caractère et sa collation il y a au moins une phase
de code de plus après traitement du jeu de caractères que la lecture d'un
binaire représentant un entier 32 bits.
le varchar possède lui aussi un traitement particulier supplémentaire car il
faut d'abord le dimensionner.
Un processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
John Mackerel a écrit:
Fred BROUARD - SQLpro wrote:
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
[...]
un NVARCHAR, compte 48 fois moins rapide.
Ces chiffres sortent-ils de mesures réelles ?
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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
************************ www.datasapiens.com *************************
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à encapsuler les jeux de caractères et collations et comment sont fait les optimisations.
On peut dire la chose suivante : entre le code binaire d'un caractère et son jeu de caractère il y a au moins une phase de code de plus que la lecture d'un binaire représentant un entier 32 bits. entre le code binaire d'un caractère et sa collation il y a au moins une phase de code de plus après traitement du jeu de caractères que la lecture d'un binaire représentant un entier 32 bits. le varchar possède lui aussi un traitement particulier supplémentaire car il faut d'abord le dimensionner. Un processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
John Mackerel a écrit:
Fred BROUARD - SQLpro wrote:
le type alpha sur 4 octets, soit 32 bits est en général 4 fois moins
[...]
un NVARCHAR, compte 48 fois moins rapide.
Ces chiffres sortent-ils de mesures réelles ?
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste 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 ************************ www.datasapiens.com *************************
see
Fred BROUARD - SQLpro wrote:
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à encapsuler les jeux de caractères et collations et comment sont fait les optimisations.
On peut dire la chose suivante : entre le code binaire d'un caractère et son jeu de caractère il y a au moins une phase de code de plus que la lecture d'un binaire représentant un entier 32 bits. entre le code binaire d'un caractère et sa collation il y a au moins une phase de code de plus après traitement du jeu de caractères que la lecture d'un binaire représentant un entier 32 bits. le varchar possède lui aussi un traitement particulier supplémentaire car il faut d'abord le dimensionner. Un processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
un ordre de grandeur pour la phase de comparaison. Cette phase de comparaison est elle réellement significative par rapport aux autres phases (lecture disque, parcours d'index, etc ...) ? Je n'en suis pas du tout convaincu.
Par rapport au type varchar, certaines bases de données (Oracle par exemple) le traite de la même façon que le type char.
-- Bruno http://errance.lirano.net
Fred BROUARD - SQLpro <brouardf@club-internet.fr> wrote:
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à
encapsuler les jeux de caractères et collations et comment sont fait les
optimisations.
On peut dire la chose suivante : entre le code binaire d'un caractère et
son jeu de caractère il y a au moins une phase de code de plus que la
lecture d'un binaire représentant un entier 32 bits. entre le code binaire
d'un caractère et sa collation il y a au moins une phase de code de plus
après traitement du jeu de caractères que la lecture d'un binaire
représentant un entier 32 bits. le varchar possède lui aussi un traitement
particulier supplémentaire car il faut d'abord le dimensionner. Un
processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
un ordre de grandeur pour la phase de comparaison. Cette phase de
comparaison est elle réellement significative par rapport aux autres
phases (lecture disque, parcours d'index, etc ...) ? Je n'en suis pas du
tout convaincu.
Par rapport au type varchar, certaines bases de données (Oracle par
exemple) le traite de la même façon que le type char.
non, théoriques car cela dépend beaucoup de la capacité du SGBDR à encapsuler les jeux de caractères et collations et comment sont fait les optimisations.
On peut dire la chose suivante : entre le code binaire d'un caractère et son jeu de caractère il y a au moins une phase de code de plus que la lecture d'un binaire représentant un entier 32 bits. entre le code binaire d'un caractère et sa collation il y a au moins une phase de code de plus après traitement du jeu de caractères que la lecture d'un binaire représentant un entier 32 bits. le varchar possède lui aussi un traitement particulier supplémentaire car il faut d'abord le dimensionner. Un processeur ne peut lire que 4 octets à la fois.
etc...
Ces données sont des ordres de grandeur.
un ordre de grandeur pour la phase de comparaison. Cette phase de comparaison est elle réellement significative par rapport aux autres phases (lecture disque, parcours d'index, etc ...) ? Je n'en suis pas du tout convaincu.
Par rapport au type varchar, certaines bases de données (Oracle par exemple) le traite de la même façon que le type char.
