Étant donné qu'une base de données nosql peut contenir d'énormes quantités de données, vous ne pouvez pas la migrer dans le sens rdbms normal. En fait, vous ne pouvez pas le faire pour les rdbms dès que vos données dépassent un certain seuil de taille. Il n'est pas pratique d'arrêter votre site pendant une journée pour ajouter un champ à une table existante, et donc avec rdbms vous finissez par faire des correctifs laids comme ajouter de nouvelles tables juste pour le champ et faire des jointures pour accéder aux données. Dans le monde nosql vous pouvez faire plusieurs choses.
- Comme d'autres l'ont suggéré, vous pouvez écrire votre code de manière à ce qu'il gère différentes "versions" du schéma possible. c'est généralement plus simple qu'il n'y paraît. De nombreux types de modifications de schéma sont faciles à coder. par exemple, si vous souhaitez ajouter un nouveau champ au schéma, vous l'ajoutez simplement à tous les nouveaux enregistrements et il sera vide sur tous les anciens enregistrements (vous n'obtiendrez pas d'erreurs "le champ n'existe pas" ou quoi que ce soit ;). si vous avez besoin d'une valeur "par défaut" pour le champ dans les anciens enregistrements, cela se fait trop trivialement dans le code.
- Une autre option et en fait la seule option sensée à l'avenir avec des changements de schéma non triviaux comme les changements de nom de champ et les changements structurels est de stocker schema_version dans CHAQUE enregistrement, et d'avoir du code pour migrer les données de n'importe quelle version à la suivante sur LIRE . c'est-à-dire que si votre version de schéma actuelle est 10 et que vous lisez un enregistrement de la base de données avec la version 7, votre couche de base de données doit appeler migrate_8, migrate_9 et migrate_10. Ainsi, les données consultées seront progressivement migrées vers la nouvelle version. et s'il n'y a pas accès, alors peu importe de quelle version il s'agit ;)
