Bonjour à tous mes futurs lecteurs. 

Sans transition, dans le cadre de mon projet de licence professionnelle je dois perfectionner une application de gestion comptable réalisée en BTS.

Je souhaite améliorer l'application desktop  que j'avais faite et y ajouter une fonction de sauvegarde des données en ligne.

Alors j'ai quelques preoccupations : 

• Vu que je souhaite utiliser l'application a la fois en ligne et hors ligne, dois je créer deux bases de données?
• Si oui, comment mettre à jour la bd en ligne?
• D'autre part, pour faciliter la lecture des données (je ne vous l'ai pas expliqué mais je compte les lire sur une interface mobile grace a une communication par api) puis-je faire communiquer une bd sql(la bd locale) et une bd nosql(la bd en ligne)?

Votre aide me serait tellement précieuse. J'ai d'ailleurs longuement hésité sur le forum adéquat pour poser mon problème 

Bonjour,

L'idée est en effet d'avoir deux bases de données, une locale et une distante. La synchronisation d'une BDD locale et d'une BDD distante est un sujet épineux. La distante étant le "maître", et la locale l'"esclave", mais pas au sens strict de la réplication, juste pour l'image ...

Selon moi une gestion comptable implique une forte intégrité référentielle, on partira donc plutôt sur du SQL plutôt que du NoSQL, en local comme distant.

La plupart des applications avec modèle relationnel ayant un mode "hors-ligne", ont un SGBD plus léger en local (type SQLite) et un serveur distant plus costaud (type PostGreSQL).

Le mode "hors-ligne" impose de clairement définir une stratégie d'usage sans connexion :

• L'utilisateur pourra-t-il continuer de créer/lire/modifier/supprimer des enregistrements alors qu'il est déconnecté du serveur distant ?
• Aura-t-il un affichage "figé" des données en sa possession au moment de la dernière connexion ?

Le choix de la stratégie d'usage va décider du développement à faire, mais sache que le premier point implique une complexité énorme : La base de données local devra être intégralement alimenter depuis le serveur (au moins lors de la première connexion), et chaque enregistrement (donc chaque table) devra disposer d'un attribut type booléen, permettant de dire si il a été modifié en local ou non pendant la période hors connexion, cela pour identifier les enregistrements qu'il faudra push sur le serveur distant ... quid des enregistrements modifiés sur le serveur distant pendant la déconnexion ... enfin tu vois le bordel ...

Le deuxième point quant à lui est plus simple à gérer. L'application locale utilise l'API pour récupérer les données du serveur distant, et les stocke en local (intégralement ou partiellement selon le besoin et la volumétrie à gérer). Dès que l'application locale détecte une perte de connexion, elle "bloque" ses fonctionnalités d'ajout, modification, suppression, elle shunte les appels API et utilise uniquement les données locales disponibles jusqu'au retour de la connexion.

Ce n'est de toute façon pas une mince affaire à gérer ...

Benzouye a écrit:

Le choix de la stratégie d'usage va décider du développement à faire, mais sache que le premier point implique une complexité énorme : La base de données local devra être intégralement alimenter depuis le serveur (au moins lors de la première connexion), et chaque enregistrement (donc chaque table) devra disposer d'un attribut type booléen, permettant de dire si il a été modifié en local ou non pendant la période hors connexion, cela pour identifier les enregistrements qu'il faudra push sur le serveur distant ... quid des enregistrements modifiés sur le serveur distant pendant la déconnexion ... enfin tu vois le bordel ...

Une possibilité est de triggerisé (insert/update/delete) la base local pour n'avoir que le différentiel des données dans une table et n'avoir que des mouvements de données à gérer (il est assez facile de générer des trigger qui vont vérifier quel champs à été mis à jour) et simplifie la gestion des différentiel

Ah d'accord. Je pars donc sur du SQL pour les deux bdd.

- Je souhaite Benzouye, continuer à faire des enregistrements, suppressions ... sur la base de données locale donc plutôt la base de données locale est le maitre et celle en ligne l'esclave.

- Par ailleurs, je me doute bien que même si c'est possible ça doit être bien galere de synchroniser du sql et du nosql... Mais je souhaitais aussi sauvegarder en ligne mes documents comptables produits par l'application afin de pouvoir y accéder à distance, (d'où le noSql)

Sur ces deux derniers points je suis encore confus... 

Didier Nyambe a écrit:

je souhaitais aussi sauvegarder en ligne mes documents comptables produits par l'application afin de pouvoir y accéder à distance, (d'où le noSql)

Je ne vois pas le rapport ...

Didier Nyambe a écrit:

plutôt la base de données locale est le maitre et celle en ligne l'esclave.

Cela signifie que tu n'as qu'un seul utilisateur ? Et la base de données en ligne n'est utilisée par personne d'autre ?

Alors oui, tu peux mettre en place une réplication maître/escale (maintenant on dirait principal/subordonné) d'un MySQL local vers un MySQL distant.

Didier Nyambe a écrit:

Je veux faire un système d'authentification sur mobile pour accéder aux données de la BD en ligne. Donc je souhaite avoir plusieurs utilisateurs de cette dernière.

Accéder aux données seulement en lecture ? Ou en lecture et écriture ?

-
Edité par Benzouye 13 août 2021 à 9:14:52

Benzouye a écrit:

Alors oui, tu peux mettre en place une réplication maître/escale (maintenant on dirait principal/subordonné) d'un MySQL local vers un MySQL distant.

Merci pour ton aide Benzouye. 

Je file me mettre au travail