Discussion :

[bmayer]

Bonjour

Je cherche à déterminer quelle type de données utiliser pour définir une PK d'une table.
Cette table fera ~2700 lignes.
La clef est une chaine de caracteres, de longueur variable entre 3 et 45 caractères, 2100 font 4 caractères, > 500 font entre 5 et 10 caractères, qq dizaines sont plus longues et ne seront probablement pas utilisées. Elles seront toutefois présentes car chargées automatiquement par un fichier.

Les tables jointes à cette table ne dépasseront pas les 10000 lignes, et seront elle même alimentées par des fichiers, seront expurgées des clefs longues (max 21 car.)

Il y aura au mieux 1 chargement par jour, jamais d'écriture hormis les corrections.

Quel compromis prendre entre
char(45), varchar() et un entier, certe performant, mais qui implique de rendre la mécanique un peu plus complexe ?

Merci d'avance

[viggovatelli]

Bonjour,

A mon avis, un entier est préférable.
Plus petit, plus simple et natif et bon pour les performances.

[FSiebert]

Bonjour,

Avec ces volumétries je pense qu'il n'y aura aucune différence de performance

[punkoff]

bonjour,


que représente cette chaine de caractere destiné a etre une pk ?

[bmayer]

Bonjour

que représente cette chaine de caractere destiné a etre une pk ?

Les noms des tables des bases de données, afin d'en faire un référencement / une cross-ref.

[punkoff]

Bonjour

Les noms des tables des bases de données, afin d'en faire un référencement / une cross-ref.

A lie : http://sqlpro.developpez.com/cours/clefs/#L1

[bmayer]

Merci à tous

[SQLpro]

Bonjour,

Avec ces volumétries je pense qu'il n'y aura aucune différence de performance

Stupide...

Imaginez que cette table soit jointe à une table comprenant 1 million de lignes et vous comprendrez alors la différence !!!

A +

[FSiebert]

Bonjour SQLpro,

Tout à fait d'accord avec votre remarque

Cependant l'auteur qui pose une question dans un cadre précis a précisé "Les tables jointes à cette table ne dépasseront pas les 10000 lignes".

Et dans le cadre de son utilisation de chargement de fichiers, ajouter une couche pour utiliser une clé numérique, compte tenu des volumétries en jeu, n'est je pense pas forcément intéressant.

[Chtulus]

Bonsoir,

Vous avez tous juste mais je tape un +1 à SQLpro, désolé !

Avez vous imaginé une montée en charge ou autre ?

Toujours prévoir que valoir !

On voit tellement de soucis aujourd'hui...;

[bmayer]

Avez vous imaginé une montée en charge ou autre ?

C'est deja au max, ce n'est pas perenne

[Chtulus]

C'est deja au max, ce n'est pas perenne

Bonsoir,

Vous êtes sûr de cela ?

C'est ce que l'on m'a dit il y a 2 ans et maintenant les volumes de certaines de nos tables ont doublés voir triplés.....

Passer 11H au taf pour reprendre le code C# ou la modélisation de la Base je vous promets que cela n'est pas dans mes habitudes

Si vous êtes certains, pas de soucis

[bmayer]

Les bases ont 10/15 ans, n'ont guère bougé. Un projet est en cours pour une migration sur completement autre chose. D'ici là, j'aimerai bien combler le manque de doc, en inventoriant les tables, leurs jobs de chargement et les rapprocher. Point barre.
Si cela devait déboucher sur qq chose d'utile, cela sera reconsidéré, des moyens seront mis en face, et sera refait, mieux.