Discussion :

[J0r_x]

Bonjour,

Je fais partie d'une équipe de développement, qui développe des applications sous SQL Server depuis pas mal de temps (< version 6.5).
J'essaye de leur inculquer la bonne marche à suivre concernant le typage des colonnes d'une table, mais il me sorte souvent, concernant les colonnes qui sont dans la primary key, qu'il ne faut pas utiliser d'autre type que le type chaine, même si la colonne contient une date, un numérique, etc ...
Apparemment lors d'une formation MSSQL Server (il y a plusieurs années) on leur aurait appris ça.

Personnellement je n'ai jamais appris ça, est-ce que ça a été d'actualité à un moment ? est-ce que ça l'ai toujours ?

[elsuket]

Bonjour,

J'essaye de leur inculquer la bonne marche à suivre concernant le typage des colonnes d'une table, mais il me sorte souvent, concernant les colonnes qui sont dans la primary key, qu'il ne faut pas utiliser d'autre type que le type chaine, même si la colonne contient une date, un numérique, etc ...
Apparemment lors d'une formation MSSQL Server (il y a plusieurs années) on leur aurait appris ça.

Personnellement je n'ai jamais appris ça, est-ce que ça a été d'actualité à un moment ? est-ce que ça l'ai toujours ?

Je vous plains ... mais je vous soutiens
Il est évident que c'est une totale absurdité, que l'on vous l'ait dit en formation ou pas ... et si c'est vrai, le formateur est un pauvre abruti

Sinon, pourquoi les éditeurs de SGBDR créent-ils plusieurs types de données ?
Heureusement, je prêche un convaincu

Le meilleur choix que l'on peut faire pour toute colonne est tout simplement le type qui correspond à ce que l'on souhaite stocker.
Il est évident que dès lors, toute requête devient très simple à écrire, et que l'on peut appliquer directement les fonctions natives sans avoir besoin d'effectuer un transtypage qui requiert un travail supplémentaire à SQL Server et au CPU du serveur qui le supporte, mais aussi aux disques.

En effet, dès lors que l'on indexe (et c'est le cas par défaut pour les contraintes de clé primaire et d'unicité, qui sont supportées par des index), moins la clé est continue, plus l'index a de chances de se fragmenter, nécessitant donc plus de lectures, plus d'occupation mémoire, ...

Bref, il n'y a pas de meilleur choix pour pourrir volontairement les performances d'une base de données

Le meilleur choix technique que l'on peut faire pour une clé primaire est une colonne de type entier avec la propriété d'auto-incrémentation (IDENTITY) : dans ce cas la fragmentation de l'index sous-jacent est quasiment tout le temps négligeable, et on évite les splits de page.

Vous trouverez également des défenseurs du type uniqueidentifier (GUID) : si la raison de l'utiliser comme clé primaire peut se défendre, il faut garder à l'esprit qu'une valeur d'un tel type occupe 16 octets ... et que la fragmentation de l'index sous-jacent est inévitable

Vous pouvez lire sur le sujet un billet que j'ai publié.
Il me semble que SQLPro et Zinzinetti en ont aussi écrit un, mais je ne parviens pas à les trouver ...

Enfin la référence

@++ et bon courage

[SQLpro]

je dirais même que si la connerie se mesurait, ce formateur servirait de mètre étalon !

Bon, c'est de l'Audiard !

A +

[EMC51]

D'accord avec Audiard...

Jamais entendu quelque chose d'aussi stupide, déjà utiliser des uniqueidentifier, j'ai hésité mais je l'ai fait sur une appli dont les données le baladaient sur plusieurs bases.

Mais des chaines... j'ai toujours entendu dire : JAMAIS

Bon courage

[J0r_x]

Merci pour vos réponse.