Clef primaire de type text ?

Le
Oriane
Bonjour,

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
?

Merci
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
SQLpro
Le #11855011
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"
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
Le #11855001
Bonjour,
"SQLpro" >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
Le #11854881
On 27 juin, 08:34, "Oriane"
Bonjour,

>"SQLpro" > >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
Le #11854821
"SQLpro" news:
On 27 juin, 08:34, "Oriane"
>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
Le #11854811
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
Le #11854661
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
Le #11854581
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
Le #11854571
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
Publicité
Poster une réponse
Anonyme