Quels sont les principaux défis liés à la création d'une application iPhone qui synchronise les données avec un serveur via des API Web?

Question

Je veux construire une application qui utilise les données d'un serveur, et il doit synchroniser les données dans l'application avec les données entrées par d'autres applications client. Donc, il y a quelques questions:

• Comment concevoir le schéma de base de données de manière efficace? Doit-il répliquer le même schéma de base de données sur le serveur ou doit-il ajouter d'autres champs & entités? Quelles sont les stratégies pour synchroniser les données, à chaque démarrage de l'application ou pendant un état inactif de l'application, ou autre chose ...
• Comment gérer les conflits de données saisies par l'utilisateur dans l'application et les données Entré par une autre application client.

Toute réponse est la bienvenue.

Answer 1

Eh bien, vous avez identifié les principaux défis dans votre question initiale. La vraie réponse est que cela a peu à voir avec l'iPhone - la réplication de base de données est juste vraiment difficile.

Voici quelques règles de base que je peux offrir:

• sens unique réplication des données est un millions de fois plus facile que la réplication bidirectionnelle, si vous pouvez vous en sortir avec elle.

• La réplication est toujours plus simple si le schéma de base de données est identique sur le client et le serveur.

• pour faire une réplication bidirectionnelle, soit vous devez stocker horodatages pour chaque ligne à chaque extrémité, ou pour stocker le contenu complet d'une extrémité à l'autre extrémité. (c'est-à-dire que le serveur doit connaître l'état le plus récent du client, ou que le client doit connaître l'état le plus récent du serveur).

• pour permettre l'ajout de lignes de clients déconnectés, vous devez identifier vos lignes à l'aide d'un GUID (ou hachage, par exemple. SHA-1), et non un champ autoincrement. Il est possible de conserver les nouvelles lignes ajoutées par le client comme «sans identificateur» jusqu'à ce que vous les synchronisiez avec le serveur, mais cette façon de faire est folle.

• aucun véritable moyen de résolution de conflit. Les options imparfaites comprennent last-writer-wins (dernière personne qui synchronise un enregistrement modifié obtient leur copie de l'enregistrement inséré), trois-way-merge (quand quelqu'un envoie un enregistrement modifié, vérifier les colonnes qu'ils ont changé, et changer seulement ces colonnes, sans écraser les modifications apportées aux autres colonnes), split-into-two-records (si deux personnes apportent des changements au même enregistrement, juste deux enregistrements et supposent que quelqu'un le corrigera éventuellement), et "demande à l'utilisateur" (qui est techniquement le plus sain, mais nécessite beaucoup de travail d'interface utilisateur et les utilisateurs comprennent rarement ce qu'un conflit même est).