Clés Primaire en VARCHAR

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
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++

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
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.

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

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 ;)

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