Je développe une application mac, en utilisant les outils objectifs-c et natifs. J'adore la mise en œuvre basée sur le document de mongodb et je prévois de l'utiliser pour stocker les données pour mon application (les données seront plus ou moins le titre de la piste musicale, avec les métadonnées qui l'accompagnent). L'objectif de l'application est de permettre aux utilisateurs de synchroniser la version de base de données de la base de données avec leur version locale. Et puis, être en mesure d'avoir toujours une version locale sur leur ordinateur, de sorte que l'Internet ne serait pas nécessaire pour utiliser l'application. Mais si l'utilisateur était hors ligne et apportait des modifications à ses données locales, les modifications seraient de nouveau synchronisées avec la base de données mongodb. Le problème que j'ai est de trouver la meilleure approche à ce problème. Le mieux que je puisse penser en ce moment, est de tirer d'abord les données de la base de données et de sérialiser les copies locales de chaque entrée "piste musicale" dans la base de données. Ainsi, hors ligne, le problème va peupler les données de ces objets sérialisés. Si l'utilisateur ajoutait/changeait des données hors ligne, les modifications seraient notées et attendraient d'être poussées vers la base de données mongodb lorsque l'utilisateur serait de nouveau en ligne. Toutes les entrées de la base de données mongodb seraient horodatées. Ainsi, lorsque l'application fonctionnait en ligne, toutes les quelques secondes, l'application pouvait comparer les horodatages de sa copie locale et de sa copie distante pour voir si des modifications avaient été apportées.Meilleure approche pour synchroniser la base de données mongodb avec la version sérialisée locale
Est-ce une bonne approche pour synchroniser des données à distance et localement à partir d'une base de données mongodb?
Votre exigence est pris en charge par CouchDB. C'est un type de base de données de type json comme mongodb mais avec une réplication automatique et une synchronisation. Si mongodb n'est pas vraiment un must, vous pouvez vouloir le considérer. – Rudy