guynemer a écrit :
Hello.
Question surement bete, mais vous est il deja arrive d'avoir epuisse le nombre d'ID (en tant que primary key) dans une base MySQL ?
|
Moi jamais. Mais je n'utilise d'index simple que pour une table n'ayant pas de parent. Pour les tables enfant, mon index est un composé.
Exemple: si j'ai une table X où chaque élément de X peut avoir plusieurs éléments de Y
Ma table X sera de ce style
1: valeur X1
2: valeur X2
3: valeur X3
...
Et chaque élément de Y sera comme ceci
1:1: valeur Y1 de X1
1:2: valeur Y2 de X1
1:3: valeur Y3 de X1
2:1: valeur Y1 de X2
2:2: valeur Y2 de X2
2:3: valeur Y3 de X2
3:1: valeur Y1 de X3
3:2: valeur Y2 de X3
3:3: valeur Y3 de X3
Et donc chaque sous-élément Y1, Y2, Y3 n'est pas obligé d'avoir un identifiant unique, l'unicité étant assurée par le couple (idX, idY)
Bien entendu, si la table Y devient elle-même référence de la table Z, alors chaque élément de Z devra répéter (idX, idY) ce qui peut éventuellement paraitre lourd. Donc à voir... Surtout que je suis sous Postgres qui peut gérer les contraintes d'intégrité référentielles sur index composés (alors que MySQL ne le peut pas).
guynemer a écrit :
Ca me parait concevable davoir plus de 4 milliards d'enregistrements, par exemple si la table est la pour conserver des stats.
Du coup comment gerer ca ? big int ? long ?
|
Tu peux utiliser bigint en unsigned => tu passes de 4 milliards à 18 milliards de milliards. T'as de quoi faire non ?
Ou alors, puisqu'il s'agit de stat, tu rajoutes à ton index un TIMESTAMP et l'unicité sera assurée par le couple (TIMESTAMP, id), lequel id n'a plus besoin d'être énorme...
---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
