est-il pénalisant en terme de performance d'utiliser des clefs primaires de
type varchar ou char ? Ou des clefs composites avec des champs de type Date
?
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
SQLpro
Plus la clef est longue moins elle sera performantes. A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus long en traitement du fait de la gestion de la collation. De plus ces types de données littéraux ne permettent pas de représenter un grand nombre de valeur. En effet tous les caractères possible d'un VARCHAR ne sont pas accessible : certains ne sont accessible que de manière hexadécimale (exemple : la sonnerie) d'autres nécessite des contorsion complexes du clavier pour être produit. Exemple e majuscule accent grave => ALT + 144 (au pavé numérique, donc impossible à réaliser sur portable...)
En définitive la plage acceptable des caractères d'un CHAR de longueur 4 ou d'un VARCHAR de longeur 2 c'est à dire de même longueur que qu'un entier INT ne permet pas plus de 1 679 616 combinaisons (donc clef différentes) alors qu'un entier de 32 bits en permet 4 millards....
A +
On 27 juin, 07:26, "Oriane" wrote:
Bonjour,
est-il pénalisant en terme de performance d'utiliser des clefs primaire s de type varchar ou char ? Ou des clefs composites avec des champs de type D ate ?
Merci
Plus la clef est longue moins elle sera performantes.
A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus
long en traitement du fait de la gestion de la collation. De plus ces
types de données littéraux ne permettent pas de représenter un grand
nombre de valeur. En effet tous les caractères possible d'un VARCHAR
ne sont pas accessible : certains ne sont accessible que de manière
hexadécimale (exemple : la sonnerie) d'autres nécessite des contorsion
complexes du clavier pour être produit. Exemple e majuscule accent
grave => ALT + 144 (au pavé numérique, donc impossible à réaliser sur
portable...)
En définitive la plage acceptable des caractères d'un CHAR de longueur
4 ou d'un VARCHAR de longeur 2 c'est à dire de même longueur que qu'un
entier INT ne permet pas plus de 1 679 616 combinaisons (donc clef
différentes) alors qu'un entier de 32 bits en permet 4 millards....
A +
On 27 juin, 07:26, "Oriane" <ori...@guermantes.fr> wrote:
Bonjour,
est-il pénalisant en terme de performance d'utiliser des clefs primaire s de
type varchar ou char ? Ou des clefs composites avec des champs de type D ate
?
Plus la clef est longue moins elle sera performantes. A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus long en traitement du fait de la gestion de la collation. De plus ces types de données littéraux ne permettent pas de représenter un grand nombre de valeur. En effet tous les caractères possible d'un VARCHAR ne sont pas accessible : certains ne sont accessible que de manière hexadécimale (exemple : la sonnerie) d'autres nécessite des contorsion complexes du clavier pour être produit. Exemple e majuscule accent grave => ALT + 144 (au pavé numérique, donc impossible à réaliser sur portable...)
En définitive la plage acceptable des caractères d'un CHAR de longueur 4 ou d'un VARCHAR de longeur 2 c'est à dire de même longueur que qu'un entier INT ne permet pas plus de 1 679 616 combinaisons (donc clef différentes) alors qu'un entier de 32 bits en permet 4 millards....
A +
On 27 juin, 07:26, "Oriane" wrote:
Bonjour,
est-il pénalisant en terme de performance d'utiliser des clefs primaire s de type varchar ou char ? Ou des clefs composites avec des champs de type D ate ?
Merci
Oriane
Bonjour,
"SQLpro" a écrit dans le message de >news: Plus la clef est longue moins elle sera performantes. A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus long en traitement du fait de la gestion de la collation. De plus ces types de données littéraux ne permettent pas de représenter un grand
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type entier en générant un nombre (par exemple incrémenté). Les exemples de base fournies par MS font ce choix (dans AdventureWorks). Mais après je dois donc utiliser cet identifiant artificiel pour accéder à les objets, et là ca ne me parait pas sensass... Alors que le choix de prendre un nom (unique pour moi) comme Primary Key est "naturel".
A moins que j'ai raté quelque chose ?
Merci de ta réponse
Bonjour,
"SQLpro" <brouardf@club-internet.fr> a écrit dans le message de
>news:1182947050.664646.312880@w5g2000hsg.googlegroups.com...
Plus la clef est longue moins elle sera performantes.
A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus
long en traitement du fait de la gestion de la collation. De plus ces
types de données littéraux ne permettent pas de représenter un grand
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type
entier en générant un nombre (par exemple incrémenté). Les exemples de base
fournies par MS font ce choix (dans AdventureWorks). Mais après je dois
donc utiliser cet identifiant artificiel pour accéder à les objets, et là ca
ne me parait pas sensass... Alors que le choix de prendre un nom (unique
pour moi) comme Primary Key est "naturel".
"SQLpro" a écrit dans le message de >news: Plus la clef est longue moins elle sera performantes. A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus long en traitement du fait de la gestion de la collation. De plus ces types de données littéraux ne permettent pas de représenter un grand
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type entier en générant un nombre (par exemple incrémenté). Les exemples de base fournies par MS font ce choix (dans AdventureWorks). Mais après je dois donc utiliser cet identifiant artificiel pour accéder à les objets, et là ca ne me parait pas sensass... Alors que le choix de prendre un nom (unique pour moi) comme Primary Key est "naturel".
A moins que j'ai raté quelque chose ?
Merci de ta réponse
SQLpro
On 27 juin, 08:34, "Oriane" wrote:
Bonjour,
>"SQLpro" a écrit dans le message de > >news: >Plus la clef est longue moins elle sera performantes. >A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus >long en traitement du fait de la gestion de la collation. De plus ces >types de données littéraux ne permettent pas de représenter un gra nd
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type entier en générant un nombre (par exemple incrémenté). Les exempl es de base fournies par MS font ce choix (dans AdventureWorks). Mais après je dois donc utiliser cet identifiant artificiel pour accéder à les objets, e t là ca ne me parait pas sensass... Alors que le choix de prendre un nom (unique pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs candidates qui doivent être implémentées sous la forme de contraintes d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
A +
A moins que j'ai raté quelque chose ?
Merci de ta réponse
On 27 juin, 08:34, "Oriane" <ori...@guermantes.fr> wrote:
Bonjour,
>"SQLpro" <broua...@club-internet.fr> a écrit dans le message de
> >news:1182947050.664646.312880@w5g2000hsg.googlegroups.com...
>Plus la clef est longue moins elle sera performantes.
>A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus
>long en traitement du fait de la gestion de la collation. De plus ces
>types de données littéraux ne permettent pas de représenter un gra nd
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type
entier en générant un nombre (par exemple incrémenté). Les exempl es de base
fournies par MS font ce choix (dans AdventureWorks). Mais après je dois
donc utiliser cet identifiant artificiel pour accéder à les objets, e t là ca
ne me parait pas sensass... Alors que le choix de prendre un nom (unique
pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs
candidates qui doivent être implémentées sous la forme de contraintes
d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
>"SQLpro" a écrit dans le message de > >news: >Plus la clef est longue moins elle sera performantes. >A longueur égale le CHAR, VARCHAR, NCHAR, NVARCHAR sera toujours plus >long en traitement du fait de la gestion de la collation. De plus ces >types de données littéraux ne permettent pas de représenter un gra nd
Merci de ta réponse. Evidemment je préférerais utiliser une clef de type entier en générant un nombre (par exemple incrémenté). Les exempl es de base fournies par MS font ce choix (dans AdventureWorks). Mais après je dois donc utiliser cet identifiant artificiel pour accéder à les objets, e t là ca ne me parait pas sensass... Alors que le choix de prendre un nom (unique pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs candidates qui doivent être implémentées sous la forme de contraintes d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
A +
A moins que j'ai raté quelque chose ?
Merci de ta réponse
Oriane
"SQLpro" a écrit dans le message de news: On 27 juin, 08:34, "Oriane" wrote:
>Merci de ta réponse. Evidemment je préférerais utiliser une clef de type >entier en générant un nombre (par exemple incrémenté). Les exemples de >base >fournies par MS font ce choix (dans AdventureWorks). Mais après je dois >donc utiliser cet identifiant artificiel pour accéder à les objets, et là >ca >ne me parait pas sensass... Alors que le choix de prendre un nom (unique >pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs candidates qui doivent être implémentées sous la forme de contraintes d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
Excuse moi mais je ne comprends pas ta réponse. Contrainte d'unicité ok, je comprends mais qu'est-ce que les clefs "candidates" ?
Merci d'avance
"SQLpro" <brouardf@club-internet.fr> a écrit dans le message de
news:1183109175.318165.285840@g4g2000hsf.googlegroups.com...
On 27 juin, 08:34, "Oriane" <ori...@guermantes.fr> wrote:
>Merci de ta réponse. Evidemment je préférerais utiliser une clef de type
>entier en générant un nombre (par exemple incrémenté). Les exemples de
>base
>fournies par MS font ce choix (dans AdventureWorks). Mais après je dois
>donc utiliser cet identifiant artificiel pour accéder à les objets, et là
>ca
>ne me parait pas sensass... Alors que le choix de prendre un nom (unique
>pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs
candidates qui doivent être implémentées sous la forme de contraintes
d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
Excuse moi mais je ne comprends pas ta réponse. Contrainte d'unicité ok, je
comprends mais qu'est-ce que les clefs "candidates" ?
"SQLpro" a écrit dans le message de news: On 27 juin, 08:34, "Oriane" wrote:
>Merci de ta réponse. Evidemment je préférerais utiliser une clef de type >entier en générant un nombre (par exemple incrémenté). Les exemples de >base >fournies par MS font ce choix (dans AdventureWorks). Mais après je dois >donc utiliser cet identifiant artificiel pour accéder à les objets, et là >ca >ne me parait pas sensass... Alors que le choix de prendre un nom (unique >pour moi) comme Primary Key est "naturel".
L'un n'empêche pas l'autre en vertu de la possibilité de clefs candidates qui doivent être implémentées sous la forme de contraintes d'unicité. Ainsi tu bénéficiera du meilleur des deux mondes.
Excuse moi mais je ne comprends pas ta réponse. Contrainte d'unicité ok, je comprends mais qu'est-ce que les clefs "candidates" ?
Merci d'avance
Oriane
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare le nom , qui est une clef candidate, avec une contrainte d'unicité, et l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je peux faire un select avec l'une ou l'autre colonne.
L'intérêt est que je peux changer de nom sans être précoccupé par les clefs étrangères puisque celles-ci vont être liées à l'identifiant. Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la clef unique.
Donc comme tu dis le meilleur des deux mondes...
Merci
A+
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare le
nom , qui est une clef candidate, avec une contrainte d'unicité, et
l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je
peux faire un select avec l'une ou l'autre colonne.
L'intérêt est que je peux changer de nom sans être précoccupé par les clefs
étrangères puisque celles-ci vont être liées à l'identifiant.
Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la clef
unique.
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare le nom , qui est une clef candidate, avec une contrainte d'unicité, et l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je peux faire un select avec l'une ou l'autre colonne.
L'intérêt est que je peux changer de nom sans être précoccupé par les clefs étrangères puisque celles-ci vont être liées à l'identifiant. Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la clef unique.
Donc comme tu dis le meilleur des deux mondes...
Merci
A+
Fred BROUARD
Oriane a écrit :
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare le nom , qui est une clef candidate, avec une contrainte d'unicité, et l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je peux faire un select avec l'une ou l'autre colonne.
EXACT !
L'intérêt est que je peux changer de nom sans être précoccupé par les clefs étrangères puisque celles-ci vont être liées à l'identifiant. Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la clef unique.
Inutile, SQL Server créé un index cluster sous la PK (Primary Key) et un index heap sous les contraintes d'unicité (UK)
Donc comme tu dis le meilleur des deux mondes...
Et tu peut choisir de ne présenter à tes utilisateurs que les clefs candidates, les autoincrément étant la mécanique sous le capot...
Merci
A+
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Oriane a écrit :
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare
le nom , qui est une clef candidate, avec une contrainte d'unicité, et
l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je
peux faire un select avec l'une ou l'autre colonne.
EXACT !
L'intérêt est que je peux changer de nom sans être précoccupé par les
clefs étrangères puisque celles-ci vont être liées à l'identifiant.
Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la
clef unique.
Inutile, SQL Server créé un index cluster sous la PK (Primary Key) et un
index heap sous les contraintes d'unicité (UK)
Donc comme tu dis le meilleur des deux mondes...
Et tu peut choisir de ne présenter à tes utilisateurs que les clefs
candidates, les autoincrément étant la mécanique sous le capot...
Merci
A+
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Bon après m'être un peu informé, je vois ce que tu veux dire. Je déclare le nom , qui est une clef candidate, avec une contrainte d'unicité, et l'identifiant, autre clef candidate, en tant que clef primaire. Ainsi je peux faire un select avec l'une ou l'autre colonne.
EXACT !
L'intérêt est que je peux changer de nom sans être précoccupé par les clefs étrangères puisque celles-ci vont être liées à l'identifiant. Je dois créer un index (ou bien est-ce fait automatiquement ?) sur la clef unique.
Inutile, SQL Server créé un index cluster sous la PK (Primary Key) et un index heap sous les contraintes d'unicité (UK)
Donc comme tu dis le meilleur des deux mondes...
Et tu peut choisir de ne présenter à tes utilisateurs que les clefs candidates, les autoincrément étant la mécanique sous le capot...
Merci
A+
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Oriane
Merci de ta réponse. Autre question corrélative: je vais devoir donc changer de schémas, car actuellement j'ai des bases installées avec des noms comme clefs primaires. Je vais donc ajouter une colonne pour chaque table, avec un type "autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs primaires. Quel est le meilleur moyen ? Je pense à une procédure PL/SQL non ?
Oriane
Merci de ta réponse.
Autre question corrélative: je vais devoir donc changer de schémas, car
actuellement j'ai des bases installées avec des noms comme clefs primaires.
Je vais donc ajouter une colonne pour chaque table, avec un type
"autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs
pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs primaires.
Quel est le meilleur moyen ? Je pense à une procédure PL/SQL non ?
Merci de ta réponse. Autre question corrélative: je vais devoir donc changer de schémas, car actuellement j'ai des bases installées avec des noms comme clefs primaires. Je vais donc ajouter une colonne pour chaque table, avec un type "autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs primaires. Quel est le meilleur moyen ? Je pense à une procédure PL/SQL non ?
Oriane
Fred BROUARD
Oriane a écrit :
Merci de ta réponse. Autre question corrélative: je vais devoir donc changer de schémas, car actuellement j'ai des bases installées avec des noms comme clefs primaires. Je vais donc ajouter une colonne pour chaque table, avec un type "autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs primaires. Quel est le meilleur moyen ? Je pense à une procédure PL/SQL non ?
Non, lourd....
Utilisez un outil de modélisation de données comme Power AMC et : 1) commencer par faire une rétro ingéniérie de la base telle qu'elle est. Ceci donnera un modèle physique.
2) Enregistrez-le en clair et à titre d'archive.
3) Puis demander à nouveau une rétro ingéniérie pour générer un modèle conceptuel.
4) Remaniez ce MCD (merise ou autre)
5) relancez la génération du MPD.
6) Enfin, demandez à Power AMC qu'il vous édite le script SQL des modifications de structure à apporter à la base de données à partir de l'archive produite à l'étape 2
Vous gagnerez un temps infini, et du temps c'est de l'argent.
Vous pouvez télépcharger une version d'essais de Power AMC valable 15 jours (voir site de Sybase).
Oriane
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Oriane a écrit :
Merci de ta réponse.
Autre question corrélative: je vais devoir donc changer de schémas, car
actuellement j'ai des bases installées avec des noms comme clefs
primaires. Je vais donc ajouter une colonne pour chaque table, avec un
type "autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs
pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs
primaires. Quel est le meilleur moyen ? Je pense à une procédure PL/SQL
non ?
Non, lourd....
Utilisez un outil de modélisation de données comme Power AMC et :
1) commencer par faire une rétro ingéniérie de la base telle qu'elle
est. Ceci donnera un modèle physique.
2) Enregistrez-le en clair et à titre d'archive.
3) Puis demander à nouveau une rétro ingéniérie pour générer un modèle
conceptuel.
4) Remaniez ce MCD (merise ou autre)
5) relancez la génération du MPD.
6) Enfin, demandez à Power AMC qu'il vous édite le script SQL des
modifications de structure à apporter à la base de données à partir de
l'archive produite à l'étape 2
Vous gagnerez un temps infini, et du temps c'est de l'argent.
Vous pouvez télépcharger une version d'essais de Power AMC valable 15
jours (voir site de Sybase).
Oriane
A +
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci de ta réponse. Autre question corrélative: je vais devoir donc changer de schémas, car actuellement j'ai des bases installées avec des noms comme clefs primaires. Je vais donc ajouter une colonne pour chaque table, avec un type "autoincrémenté". Jusque là pas de blème.
Après il va falloir que je modifie toutes les relations clefs pimaires/étrangères, pour qu'elles utilisent mes nouvelles clefs primaires. Quel est le meilleur moyen ? Je pense à une procédure PL/SQL non ?
Non, lourd....
Utilisez un outil de modélisation de données comme Power AMC et : 1) commencer par faire une rétro ingéniérie de la base telle qu'elle est. Ceci donnera un modèle physique.
2) Enregistrez-le en clair et à titre d'archive.
3) Puis demander à nouveau une rétro ingéniérie pour générer un modèle conceptuel.
4) Remaniez ce MCD (merise ou autre)
5) relancez la génération du MPD.
6) Enfin, demandez à Power AMC qu'il vous édite le script SQL des modifications de structure à apporter à la base de données à partir de l'archive produite à l'étape 2
Vous gagnerez un temps infini, et du temps c'est de l'argent.
Vous pouvez télépcharger une version d'essais de Power AMC valable 15 jours (voir site de Sybase).
Oriane
A +
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
