Clés Primaire en VARCHARRésolu

Question

Bonjour,


Je souhaite créer des clés primaires en VARCHAR(30), mais j'ai peur que
ce soit plus lent qu'avec un INTEGER ou un INTEGER Autoincrémental.


surtout pour les références vers d'autres tables, les recherches ou les liens...


Quelqu'un pourrait t'il me dire de quoi il en retourne.


J'explique la raison : je gère une numéro incrémental unique pour ma
base de donnée. mais je ne souhaite pas être limité par une integer à
11 digits par exemple, et également permettre d'ajouter des préfixes
sur les valeurs de ces champs pour identifier par exemple, le lieux ou
son saisie les données.

(utile pour la synchro multisite)...


Si vous voyez un inconvénient, ou des problèmes liésx à cela, ou bien
d'autres solutions, merci de me tenir informé, avant que ma base de
donnée ne soit terminée !!!.... ça m'aiderai beaucoup...


MERCI d'avance.


(Ps : Je travaille en MySQL pour modéliser la maquette, mais le final
pourra être migré sur oracle ou Sqlserver ou postgrésql....)

Fabien FERT [:)]
www.sigmadia.fr.fm

crilun · Answer

crilun

salut,

un varchar sera toujours plus long sur une requete select qu'un integer,

sachant que tu veut identifier les lieux ou sont saisies les données je
pense qu'il serait plus judicieux de mettre 2 clefs à ta table avec un
colonne de plus, une contenant un numero et l'autre le lieu,meme si
pour cela tu doit gerer l'autoincrement toi meme,

car d'apres ce que tu dis si tu ne veut pas etre limité à 11 digits
c'est que ta table va contenir un nombre important d'enregistrements,

par consequent l'insert etant plus rare que le select il vaut mieux privilegier le select, 

donc je pense que l'ajout d'une colonne en restant sur des champs integer sera plus judicieux,

j'ai eu moi meme à faire une requete sur une table dont la clef etait
un varchar et ou le nombre d'enregistrements etaient nombreux et malgré
la présence de blade relativement puissant cela prenait quand meme du
temps depassant parfois le time out.

donc en résumé préfere la séparation de champs en restant sur des integer.


ci@o++

ffert · Answer

En fait, je veux gérer un identifiant unique pour l'ensemble de mes tables et de mes bases de données.
J'ai 4 bases de données de natures différentes (MySQL, FoxPRo, Access, MSSQL). La plus importante est FoxPro avec plusieurs de ces  tables pouvant avoir entre 400 000 à 500 000 nouveaux enrregistrement chaque années.
Si je prend un integer 11 et un préfix de 3 (999 lieu pour avoir plus de marge que 2 pour 99)... il ne me reste que 8 digits pour numéroté les enregistrements des 4 databases, ça me semble un peu juste dans la durée... (autonomie de 2 à 3 ans je pense).

Mais la structure de mon système impose un ID unique pour l'ensemble des 4 bases de données toutes tables confondues !!!!!!!
(Il se peut que dans un avenir proche je connecte de l'ORACLE)...

L'idée de prendre 2 champs n'est pas mauvaise, mais le problème c'est que d'autres utilisateurs pourront rajouter d'autres tables ou bien, pourront se connecter sur des tables existantes... ça obligerait alors à changer la structure de leur code en profondeur car, les ID ne serait plus sur un mais 2 champs.

Et si je prenais des CHAR(20) au lieu de VARCHAR(20) ? ça ne serait pas un peu plus rapide ?
Ou bien un autre type ?
Puis-je créer mes propres type (je crois que c'est faisable sur MySQL ? non mais je ne sais pas comment faire.)

Si vraiment je peux pas faire autrement je prendrais deux champs, mais ça ne m'arrange pas. Existe t'il des solutions pour permettre à des bases de données d'accepter des INTEGER de 20 digit  par exemple, en créant son propre type d'integer ?? (je ne pense pas car ça doit faire partie du code compilé du serveur de base de donnée.)

Merci d'avance pour vos réponses.

Fabien FERT [:)]
www.sigmadia.fr.fm

crilun · Answer

crilun

pourrait tu expliquer dans quel mesure les utilisateurs accèdent à tel ou tel type de base?

par ce qe j'ai bien un truc à te proposer mais je ne suis pas sur que ca marche dans ton cas,

c'est de mettre toujours 2 champs integer mais cette fois tu en
rajoutes un 3ieme que tu rempli avec un trigger et qui est la
concatenation des 2 premiers et qui lui est un varchar, ce qui te
permet d'avoir les 2 premiers champs si tu veut obtenir des requetes
plus rapide, ainsi que le 3ieme champ unique qui te permet de conserver
ta structure.


pour ce qui est de la difference entre le char et la varchar je ne sais pas si l'un est plu rapide ou non que l'autre,


pour ce qui est de la creation des types que veut tu dire par la? tu
parles peut etre de contrainte qui impose à un champ de repondre à un
expression reguliere? masi ce n'est pas une optimisation car ca oblige
le system a tester l'expression systematiquement et l'expression reste
toutjours un varchar quand meme.

cs_Malkuth · Answer

SALUT,
 
et si tu prenait un entier long 64 bit (bigint sur sqlserver)
2^64 =18446744073709551616

18446744073709551616 id Différent ca fais déjà beaucoup mais tu ne dis pas clairement de combien d'ID tu as besoin par an donc quand a savoir l'autonomie que ca te donnerai ...

ffert · Answer

L'idée du BigInt me semble une trés trés bonne solution qui conviendrai à mes besoins je pense.

Mais qu'en est-il de l'utilisation des BIGINT en tant que clés primaire ?

à mon avis ça sera toujours plus rapide que les varchar. mais y a-t'il
des contraintes particulières à utiliser des BigInt en tant que clé
primaire ? (vue que nos serveurs ne sont  pas encore 64 bit... et
que j'ai lu quelque part que faire traiter un objet 64 bits par un
processeur 32 bit prenais plus de temps que le double (2 x 32)... Mais
réflexion faite ça sera tout de même plus rapide qu'un varchar je
pense...)


j'attend vos ultimes conseils. MERCI à tous d'avoir répondu. ça m'aide bien.

Merci

Fabien FERT [:)]
www.sigmadia.fr.fm

cs_Malkuth · Answer

Le probléme du varchar c'est que tu vas utiliser les chiffres et (peut être les lettres) donc tu vas codé tes élément sur 30*8bits(240 bits) (et je parle pas d'un nvarchar) alors que tous ces bits ne seront pas des bit utiles, il sera toujours plus rapide de faire une recherche sur un element de 64bit que 240.

Enfin se sera plus long qu'un entier certe mais l'entier ne répondant pas a tes attente il faut bien accepter le sacrifice. Et de plus tous les clients n'auront que des int a changer par des long ca devrait pas être trop problèmatique ;)

ffert · Answer

MERCI BEAUCOUP.


Je vais tester la solution avec les BIGINT.


Vue que les ID sont unique sur l'ensemble de chaque base de donnée, les
requêtes multitables (avec jointure) devrais être un petit peu plus
rapide. Il me semble.


En tout cas merci à tous. pour les tuyaux...

Fabien FERT [:)]
www.sigmadia.fr.fm

Clés Primaire en VARCHAR

7 réponses

Votre réponse

Discussions similaires