Parfaitement d'accord avec toi sur la prise en compte des cas improbables. Le système en question n'est qu'un sous système d'un système plus grand de surveillance démographique. Chaque individu est rattaché à un ménage qui est rattaché à une concession. Donc les agents de saisi on plusieurs infos de référence autre que les noms et prénoms.
Le 21/06/2014 05:32, Lien Rag a écrit : > > Un événement improbable ne doit pas être traité comme un événement > impossible... > Et le code doit donc prévoir son existence. > > Si le cas est suffisamment rare (ce que tu semble indiquer) faire une > alerte qui amènera l'intervention d'un opérateur humain est > effectivement le moyen le plus simple de procéder (on ne fait pas plus > flexible qu'un humain), mais il faut être sûr que l'humain saura > comment procéder et disposera des informations nécessaires (i.e, la > donnée avant modification, la première modification, la seconde > modification, et les suivantes éventuellement). > > En Europe le nomadisme médical est assez fréquent, je ne sais ce qu'il > en est ici... mais ce serait dommage de l'apprendre parceque ta base > de données a explosé! > > Comment tu gères les problèmes d'homonymie d'ailleurs? > Tu n'as pas de risque d'erreur de saisie par les opérateurs? > > > On 20/06/2014 20:06, T. Idriss TINTO wrote: >> Théoriquement une données peut être modifiée dans n'importe quel >> village. Et il est vrai que si une donnée est modifiée dans plus d'un >> village, le soir ça va être difficile de prendre en compte les >> modification de tous. Mais dans la pratique, le problème ne se pose pas >> vraiment, parce qu'il s'agit de gérer les consultations prénatales des >> femmes. Il est difficile d'imaginer une femme aller dans plusieurs >> centres de santé (plusieurs villages) le même jour pour la même >> consultation. >> Cependant, Si cela arrivait, on pourrait signaler le conflit afin qu''il >> soit corrigé par un administrateur. >> >> regards >> >> Le 20/06/2014 19:22, Lien Rag a écrit : >>> J'ai oublié de poser une question importante: ce sont les mêmes donnés >>> qui peuvent être modifiées dans les 5 villages? >>> Et dans ce cas comment tu prioritises une modification sur l'autre? >>> >>> On 20/06/2014 17:48, Lien Rag wrote: >>>> hasher tes données et comparer systématiquement les hash ne résoud >>>> pas ton problème? >>>> Et si tu ne crains pas une attaque tu peux même utiliser un simple >>>> MD5 si j'ai bien compris, il n'y a aucun risque de confusion >>>> accidentelle (par contre le MD5 est vulnérable à une imposture par >>>> quelqu'un de vraiment doué)... >>>> >>>> On 20/06/2014 13:26, T. Idriss TINTO wrote: >>>>> Bonjour, >>>>> >>>>> Merci Lien, c'est surtout la conception qui m’intéresse. >>>>> Les écritures partielles, je n'aurai pas à m'en soucier si j'arrive à >>>>> adapter les concepts existants. >>>>> L'exigence est que l'ensemble des bases doivent avoir les même >>>>> données, >>>>> pas en temps réel mais au moins à la fin de la journée. Donc aucune >>>>> architecture n'est encore choisit. >>>>> La réplication maitre-esclave de MySQL aurait été bien, mais les >>>>> écritures se font dans le maître, alors que dans mon cas, je n'ai >>>>> aucune >>>>> assurance que le maître restera connecté à l'esclave. >>>>> Apparemment un système multi-maitre marcherai, mais je ne maîtrise >>>>> pas >>>>> encore bien le comportement du système en cas de déconnexion puis >>>>> reconnexion d'un maître. >>>>> >>>>> Regards >>>>> >>>>> Le 20/06/2014 00:02, Lien Rag a écrit : >>>>>> Pour le code lui-même, je ne peux pas t'aider... >>>>>> >>>>>> Pour la conception, je suppose que ce que tu crains c'est des >>>>>> écritures partielles? >>>>>> Est-ce que tu as une base de données mère? >>>>>> >>>>>> Le principe dans ce genre de cas sensible c'est de ne pas faire >>>>>> d'écriture en dur (dans la base elle-même) avant d'avoir eu >>>>>> confirmation que tout c'est bien passé: tu stockes dans des >>>>>> variables >>>>>> temporaires en attendant que toute l'opération d'échanges de données >>>>>> soit terminée. A ce moment-là tu envoies une validation et les >>>>>> variables temporaires sont toutes écrites en base. >>>>>> >>>>>> Maintenant peut-être que c'est évident pour tout le monde, dans >>>>>> ce cas >>>>>> je me tais et laisse les pros parler. >>>>>> >>>>>> On 19/06/2014 14:30, T. Idriss TINTO wrote: >>>>>>> Bonjour à tous, >>>>>>> >>>>>>> J'ai une problématique et je viens quérir votre aide. >>>>>>> >>>>>>> J'ai 5 PC répartis dans 5 villages et sur lesquelles tourne une >>>>>>> application exploitant une base de données MySQL et j'ai un serveur >>>>>>> central dans une autre zone géographique. >>>>>>> Je veux qu'à la fin de la soirée, toutes mes 6 bases MySQL soient >>>>>>> synchronisées. >>>>>>> >>>>>>> Comme technologie d'interconnexion, j'utilise un GPRS pas du tout >>>>>>> stable. >>>>>>> >>>>>>> Merci d'avance >>>>>>> >>>>>>> >>>>>>> > > > -- > Ce message a été envoyé à la liste libre@dakarlug.org > Gestion de votre abonnement : http://dakarlug.org/liste > Archives : http://news.gmane.org/gmane.org.user-groups.linux.dakarlug > Le site du DakarLUG : http://dakarlug.org -- Teg-Wendé Idriss TINTO: Ingenieur en Informatique téléphones: (00226)70102936, (00226)66283666 email: tinto.jean[at]titinto[dot]net, tinto.jean[at]computer[dot]org twitter: @titinto_ skype: tinto.jean citation: « Notre mission est de préserver, protéger et promouvoir la liberté d'utiliser, étudier, copier, modifier et redistribuer les programmes informatiques, et de défendre les droits des utilisateurs de logiciel libre. » FSF
0xA36BDC8F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
-- Ce message a été envoyé à la liste libre@dakarlug.org Gestion de votre abonnement : http://dakarlug.org/liste Archives : http://news.gmane.org/gmane.org.user-groups.linux.dakarlug Le site du DakarLUG : http://dakarlug.org
