Il est très facile de remplir une base de données. Il est plus difficile de faire grossir une base de données et de répondre rapidement aux besoins des utilisateurs. En effet, avec l’augmentation du volume de données à traiter, il est fréquent que la base de données ralentisse.
Le travail des bases de données, c’est de stocker des données de façon fiable (voir le concept d’ACID). Vérifier que les données sont justes coûte (du temps, des machines, des algorithmes, du stockage…) et plus les données sont importantes, plus il coûte d’assurer cette tâche de fiabilisation de données.
Cela n’est pas un problème de base de données. C’est un problème de gestion des données / ressources et on trouve souvent les mêmes cas de figure :
- Une mauvaise utilisation des concepts fondamentaux liés aux bases de données (types de champs, indexes…) et à la modélisation (Merise est difficile à maîtriser).
- Une mauvaise utilisation des spécificités de chaque SGBDR (tous les SGBDR n’applique pas de la même façon les standards des bases de données).
- Les machines ne sont pas suffisamment dimensionnées pour absorber le volume de données et les demandes des utilisateurs.
- Les requêtes ne sont pas optimisées et sont trop gourmandes.
- Les données sont trop importantes. Faire le ménage et archiver est nécessaire et inéluctable.
- Une inadéquation entre la situation actuelle et le besoin imaginée (lors de la conception / dernière refonte).
Alors, oui, faire grossir une base de données tout en conservant ses performances est un vrai travail qui nécessite des compétences. Non, ce n’est pas infaisable. La solution de facilité étant de mettre plus de budget dans l’infrastructure. La solution idéale étant de se plonger dans la base pour l’optimiser, l’alléger puis éventuellement adapter l’architecture et l’infrastructure.
