Concept de partitionnement d'une base de données

Bonjour,
- je n'ai pas d'index sur la combinaison n° du ticket et date du ticket , mais j'ai une clé primaire sur le champ idGain qui est numérique et incrémental.
- Il ne peut pas avoir 2 numéro de tickets identiques à une même date , mais on peut avoir un même numéro de tickets sur 2 dates différentes.
- Les tickets périmés sont gardés dans la base de données jusqu'en fin d'année et archivés après le 5 janvier du mois de l'année suivante , délai de validité des tickets de l'année antérieure.
- Les recherches ne sont pas lentes dans les bases de données distribuées. Le formulaire de recherche et de validation de tickets pointe sur une vue qui filtre les tickets valides et je ne sais pas si ce schéma sera efficace dans une base de données centralisée où j'aurai à une même date près d'un million de ticket.
- je suis satisfait des performances des insertions dans la base, mais quand il y a beaucoup de tickets valides dans la base ( parce qu'il y a eu beaucoup de gagnants), l'utilisateur ressent un peu de lenteur dans sa base régionale.Et je me demande ce qui arrivera quand je vais centraliser 5 régions dans une même base et qu'il y ait beaucoup de gagnants .


Merci de vouloir m'aider

Excusez moi, après vérification , je me suis rendu compte que la table n'est pas indexé sur sur le n° du ticket et la date du ticket, mais qu'il existe plutôt un champ idGain qui est la clé primaire.
Un ticket émis est valable pour toutes les 5 régions et unique sur tout le pays à la même date. mais pour qu'un ticket émis dans une région soit payé dans un autre région, on doit appelé au téléphone pour s’assurer que le ticket est bien valable; et c'est justement pour éviter ces appels que nous voulons centralises toutes les bases de données.
Les tickets périmés (après 5 jours) sont-ils gardés dans la même table que les tickets valides? Moi j'envisagerais de changer cela, et de les déplacer vers une autre table.-> Nous avons créé une vue pour extraire les tickets valides (inférieur ou égal à 5 jours), le formulaire de recherche de ticket pointe sur cette vue . Ça ne sera pas efficace alors?

L'idée de déplacer les tickets périmés vers une autre table est intéressante, mais un peu radicale; puisque j’aurais besoin de 2 tables et d'une vue pour agréger les 2 tables pour des besoins statistiques. En indexant le n° du ticket et la date du ticket, ça ne pourra pas accélérer les recherches des tickets? Le concept de partitionnement de la table ne peut pas m'aider ici?
Merci