Bonjour,
 
Pour schématiser, notre structure repose sur 3 serveurs principaux : Un serveur Web (2003 Serveur / IIS), un serveur de BDD (2003 Serveur / MySQL), un serveur de documents (2003 server).
La problématique à laquelle nous sommes aujourd’hui confronté concerne MySQL ;
 
Nous avons actuellement une table qu’on appellera ici « table » avec environs 1 300 000 enregistrements actuellement mais qui est amenée à grossir fortement.
Elle a comme clé primaire / identifiant, un champs « idobjet » : varchar(30)
Ces « idobjet » nous sont transmis par nos clients quotidiennement.
Chaque client dispose d’une plage étendue de numéro d'objet. Lorsqu’il arrive en fin de plage il est sensé en obtenir une nouvelle…
 
Cet « idobjet» était donc sensé être unique, mais avec le temps, les clients (soumis aux contraintes d'un logiciel du fournisseur dont on a pas la main…) repartent au début de leur plage allouée.
De ce fait tous les nouveaux objet qu’ils nous transmettent ne peuvent pas être insérés en base chez nous pour cause de doublon…
 
Nous avons un certain temps pensé à utiliser comme clé primaire un id numérique en auto incrément mais le risque d’atteindre la valeur maximale est trop important il me semble.
 
Nous avons donc 2 pistes :
 
Soit, utiliser une double clé primaire sur 2 champs : « idobjet» et « date » (jour mois année) empêchant ainsi tout doublon.
(sauf en cas de réédition sur une même journée mais le cas est « impossible » en pratique et, si il y avait des doublons dans ce cas nous ne les enregistrerions pas en base à juste titre)
 
Soit, utiliser une clé primaire sur un champs unique qui serait la concaténation du champs « idobjet» et « date » séparé par un tiret par exemple.
Le principe de doublon reste le même que ci-dessus et nous conviendrai)
 
La solution 1 me semble plus « propre » mais plus lourde pour reprendre tout le code (ajout de la double clé dans toutes les requêtes)
 
La solution 2 serait plus « simple » à mettre en œuvre mais j’ai peur des performance lors de recherches ou autre sur un si grand champs…
 
Que nous conseilleriez-vous ?
MySQL lorsqu’il a une clé sur 2 champs se contente-t-il de concaténer les deux champs en question pour se former sa clé ?
 
Un grand merci par avance !

 
t'as de la marge encore.

Effectivement, je ne pensait pas qu'on pouvait aller aussi loin à ma connaissance...
C'est l'équivalent du BigInt ?
 
Même si la marge est correcte, le problème reste possible... (je psychote oui...)
 
Je suppose que MySQL sera plus performant sur du numérique que du varchar ?

C'est clair qu'avec un unsigned bigint, y'a de la marge. Sinon, après, y'a le système de tables partitionnées. Par ailleurs, il me semble que c'est plus performant de mettre une clé primaire sur un type entier que varchar

Mieux vaut utiliser un int au lieu d'un bigint (enfin l'equivalent MySQL), ca prends 2x moins de place
 
INT: -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647)
La version unsigned va jusqu'a 4 millards evidement.
 
C'est pas une question de risque d'arriver a la valeur maximale, vous aurez d'autres problemes bien avant ca, en autre un probleme d'espace te de performance.
 
De plus utiliser une grande clé primaire est mauvais pour les perfs, la clé primaire se retrouve dans tous les indexes et est utilisée pour les lookups.