Une réponse philosophique :les bases de données sous-optimales (relationnelles) regorgent d'anomalies d'insertion, de mise à jour et de suppression. Tout cela conduit à des données incohérentes, entraînant une mauvaise qualité des données. Si vous ne pouvez pas faire confiance à l'exactitude de vos données, à quoi cela sert-il ? Demandez-vous ceci :voulez-vous les bonnes réponses plus lentement ou voulez-vous les mauvaises réponses plus rapidement ?
En pratique :faites-le bien avant de le faire rapidement. Nous, les humains, sommes très mauvais pour prédire où les goulots d'étranglement se produiront. Améliorez la base de données, mesurez les performances sur une période de temps décente, puis décidez si vous devez la rendre plus rapide. Avant de dénormaliser et de sacrifier la précision, essayez d'autres techniques :pouvez-vous obtenir un serveur, une connexion, un pilote de base de données plus rapides, etc. ? Les procédures stockées pourraient-elles accélérer les choses ? Comment sont les index et leurs facteurs de remplissage ? Si ces techniques et d'autres techniques de performance et de réglage ne fonctionnent pas, envisagez alors la dénormalisation. Ensuite, mesurez les performances pour vérifier que vous avez obtenu l'augmentation de vitesse pour laquelle vous avez "payé". Assurez-vous que vous effectuez une optimisation et non une pessimisation.
[modifier]
R :Bien sûr.
- Effectuez une sauvegarde.
- Effectuez une autre sauvegarde sur un autre appareil.
- Créer de nouvelles tables avec des commandes de type "sélectionner dans une nouvelle table à partir d'une ancienne table...". Vous devrez effectuer des jointures pour combiner des tables auparavant distinctes.
- Laissez tomber les anciennes tables.
- Renommer les nouvelles tables.
MAIS ... envisagez une approche plus robuste :
Créez des vues sur vos tables entièrement normalisées dès maintenant. Ces vues (tables virtuelles, "fenêtres" sur les données... demandez-moi si vous voulez en savoir plus sur ce sujet) auraient la même requête de définition que l'étape trois ci-dessus. Lorsque vous écrivez votre application ou la logique de la couche DB, utilisez les vues (au moins pour l'accès en lecture ; les vues pouvant être mises à jour sont... eh bien, intéressantes). Ensuite, si vous dénormalisez plus tard, créez une nouvelle table comme ci-dessus, supprimez la vue, renommez la nouvelle table de base quelle que soit la vue. Votre application/couche DB ne verra pas la différence.
Il y a en fait plus à cela dans la pratique, mais cela devrait vous aider à démarrer.
