ConceptionRésolu

Question

Bonjour à tous!
 Je dois développer une application PHP/MySQL qui sera
déclinée en deux version, appelons les maître et esclave. On utilise
des critères stockés dans la base de données pour effectuer diverses
tâches. La différence entre maître et esclave est que maître ne peut
pas modifier ces critères. Je devrai donc pouvoir faire un export des
modifications de certaines tables de maître pour les importer dans
esclave (export que je pense faire en XML, mais si vous me proposez
mieux?...)


Voici mes deux question:

1) Comment gérer l'exportation? Ai-je intérêt à créer sous maître une
table dans laquelle j'écris des trucs genre: l'item XX a été modifié;
l'item XX à été supprimé; ... Table que j'utiliserais pour effectuer
mon export? Ou bien je garde la table initiale quelque part et je bosse
avec des jointures? Ou.... ?


2) Au niveau de l'importation. Si un élément a été supprimé de maître,
je ne devrai plus pouvoir l'utiliser mais je ne peux pas forcément le
supprimer s'il en existe une référence dans l'un des tables esclaves.
Je pensais, pour chaque table, inclure un flag "actif" que, dans ce cas
je passerai à 0 pour ne plus pouvoir utiliser cet item pour de
nouvelles insertions tout en le laissant disponible...


Voilà, j'espère avoir été clair.Auriez-vous quelques pistes?


Merci!


@++

R@f

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

malalam · Accepted Answer

Hi, oui mais avec ton système d'updates sur les bases esclaves, cela t'oblige aussi à mettre à jour les scripts PHP qui tournent sur les serveurs esclaves ? Alors que si c'est la base maîtresse qui gère les historiques (flag actif/inactif), et que les base esclaves se contentent d'avoir juste les données actives, leur script php restera à jour la plupart du temps, non ? Enfin chais pas, c'est flou sans avoir plus de détails sur le type d'applicatif que tu développes. Pour moi le concept habituel c'est que la base maîtresse possède LA vérité, l'histoire de l'applicatif, et le script le plus complexe pour gérer tout ça. C'est le principe du client/serveur, en fait, adapté au offline. Je m'explique avec un tout petit exemple : Base maîtresse : tableid 1, actif 1id 2, actif 1 Base esclave : id = 1 id = 2 Script maître : Histo : Script esclave : Display Mise à jour : Base maîtresse table id 1, actif 1 id 2, actif 0 Base esclave : id = 1 Si tu rajoutes des contraintes, c'est le script maître qui se complexifie, mais le script esclave restera le même (mises à jour majeures pour cause de nouvelles fonctionnalités mises à part). Mais bon...sans en savoir plus, difficile de t'aider plus avant : il y tjrs des exceptions, des cas spécifiques qui justifient des modèles extraordinaires. Donc si ça se trouve, tu as tout à fait raison. Je ne vois juste pas pourquoi, pour le moment, parce que, sans doute, je manque d'éléments. Pour ce qui est des mises à jour, le XML me semble très adapté. C'est lisible sur toute plateforme sans problème.

neigedhiver · Answer

Salut,

MySQL 5 implémente les Vues : ce sont des "résultats de requêtes" accessibles comme des tables, mais uniquement en lecture, et mis à jour dynamiquement.
Par exemple, on souhaite ne mettre à disposition que quelques champs récupérés dans 2 tables. On ne souhaite pas qu'ils puissent être modifiés et que les autres champs des tables en question ne soient pas consultables (il faut que les permissions de l'utilisateur n'autorisent pas l'accès aux tables en question). Plutôt que de jongler avec les permissions (autoriser un utilisateur sur telle table et y autoriser l'accès en lecture à quelques champs uniquement, ce qui n'est pas viable avec plusieurs utilisateurs) on peut utiliser une vue.
La vue sera constituée des champs que l'on souhaite laisser en consultation. Elle ne permettra pas de les modifier, et la vue sera mise à jour dynamiquement quand les tables sont mises à jour.

C'est je pense le plus sain en terme de conception : importer / exporter présente de nombreux inconvénients, parmi lesquels la synchronisation des données. Si la base est très petite, ce n'est pas gênant de faire un petit script qui va exporter le contenu dans une autre base, même si c'est des ressources consommées pour pas grand chose. Si la base est plus volumineuse, ça devient carrément mortel (au sens propre du terme) pour les performances du serveur.

<hr size="2" width="100%" />Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

coockiesch · Answer

Salut!
  Merci pour ta réponse. Mais est ce que ton idée peut jouer sachant que les tables maîtres et esclaves ne sont pas sur le même serveur et n'ont aucun moyen de communiquer?

Merci!

Raf

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

neigedhiver · Answer

Mon idée consiste à ne pas les mettre sur des serveurs différents.

Soit ta base de données est vraiment volumineuse et nécessite beaucoup de ressources cpu, dans ce cas tu peux envisager de la mettre en clusters.
Sinon, laisse tout sur le même serveur. Les rares cas où l'on va séparer des tables sur des serveurs différents, sont également des cas où on va avoir un problème de performances, et où les tables en lecture seule ont besoin d'être très très rapides et subissent beaucoup d'accès.
Autrement, ce n'est pas vraiment justifié.

Pour répondre plus exactement à ta question, je ne sais pas si les vues peuvent accéder à des bases ou même des serveurs différents. A mon avis, la doc de MySQL te donnera la réponse à cette question (même s'il faudra sûrement chercher un peu, tellement elle n'est pas bien bien foutue).

<hr size="2" width="100%" />Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

coockiesch · Answer

Salut!
  En fait je n'ai pas le choix d'utiliser des serveurs différents: j'ai  une application qui sera distribuée à divers établissements...

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

neigedhiver · Answer

Et le tout sans réseau ? C'est pas mission impossible, mais ça y ressemble... Personnellement, je trouve qu'utiliser des bases identiques sans réseau, c'est anti-productif. Mais bon... On fait pas toujours ce qu'on veut, et ceux qui prennent les décisions ne sont pas toujours les plus compétents.

Ce que je n'arrive pas à comprendre, c'est pourquoi une donnée supprimée dans la base "maitre" devrait pouvoir être encore utilisée dans la base esclave... Ca me parait absurde : un enregistrement ne devrait être supprimé que s'il n'est plus utilisé. C'est pour cela que certains moteurs de tables (InnoDB par exemple) gèrent l'intégrité des données grâce, entre autres, aux clé étrangères (inconnues dans MyISAM, le moteur par défaut de MySQL) et aux suppressions en cascade. C'est encore lié à l'absence de communication entre les bases.
Tu vas être obligé de gérer manuellement (via des scripts adéquats) ce qu'un réseau aurait permis nativement.

A partir de là, à peu près tout est permis : tu vas devoir gérer comme tu le peux la suppression de données dans la base lors de l'import, que tu devras gérer manuellement, au lieu d'importer un fichier sql ou autre. Pour cela, lors de l'import, tu peux :
 - utiliser un fichier csv, le comparer à la version précédente et traiter les conflits manuellement (bon courage)
- logguer les requêtes de suppression, ou simplement les tables et les id des enregistrements supprimés, et, encore une fois, traiter les conflits manuellement
- importer violemment les données et écraser les anciennes, et gérer ensuite le comportement de l'application quand elle rencontre le cas d'une donnée qui n'existe plus.

Bref, en ce qui me concerne, je n'ai pas beaucoup d'idées sur comment gérer ça. Peut-être que si tu donnes un peu plus de détails sur ton application, on pourrait y voir un peu plus clair et te proposer des solutions alternatives plus pratiques...

<hr size="2" width="100%" />Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

coockiesch · Answer

Salut! :)
  Oki, je vais recommencer en tâchant d'être plus clair!

Je dois développer une application permettant de mettre en place des mesures de contraintes pour des personnes âgées. Un certain nombre de personnes vont établir la base de données (maître) contenant mes items: quelles sont ces mesures, à quoi faut-il faire attention, quelles sont les mesures alternatives moins contraignantes, ... Et l'appli sera distribuée. Les utilisateur ne pourront pas modifier ces éléments dans les bases esclaves car on veut garantir que tout la procédure est respectée.

Au bout de quelques temps, le comité de pilotage du projet peut décider de supprimer des mesures ou de les modifier. Je dois donc prévoir un moyen de pouvoir mettre à jour les bases de données esclaves (par contre, si j'utilise un fichier XML, il peut être envoyé aux différents établissements par email, j'ai pas besoin de créer un téléchargement ftp, ou autre).

Et là viennent mes questions de mise à jour. Je ne peux pas par contre juste supprimer certains de ces éléments car si on décide de ne plus les utiliser à l'avenir, des autres éléments de la base de données y font peut être encore référence: je devrai peut être les laisser en mémoire et juste prévoir un champ "utilisable", valant 0 ou 1.

Est-ce que je me suis mieux exprimé ou c'est tjs confus?

En tout cas, merci pour tes réponses! :-)

Raf

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

malalam · Answer

Hello,

moi je ne pige pas bien Raf, désolé :-)
- si les éléments supprimés de ta base maître sont tjrs référencés dans tes bases esclaves (ça, je peux le comprendre), comment, néanmoins, comptes-tu gérer cette suppression ? Que vont faire les bases esclaves avec ce flag "inactif"? Ca ne change pas grand chose au problème...tu dois quand même gérer l'inactivité (de même que tu devrais gérer la suppression si tu les supprimais).
Je ne suis pas d'accord avec toi sur le fait que ce sont les bases esclaves qui devraient contenir ce flag, même si je suis d'accord avec le flag : les bases esclaves doivent pouvoir gérer la suppression d'un élément (plutôt le script associé doit pouvoir la gérer), et c'est à ta base maître de conserver l'historique des évolutions. Déjà, ça ne te fera qu'une base conséquente, pas X bases...
- ensuite l'export/import, qui va avec en fait : à mon sens, c'est à la base maître d'agir; elle est LA référence et doit le rester; c'est à elle d'aller mettre à jour les bases esclaves, pas l'inverse. Pour ça, un CRON suffit (une mise à jour en temps réel pouvant poser des problèmes de performance en utilisation maximale, alors qu'un CRON tournant de nuit aura sans doute moins d'impact). Ce CRON aura la tâche de supprimer les éléments devenus caduques par exemple. En amont, un script doit gérer les "suppressions" de la base maître, à savoir, les flaguer...(en temps réel, là, ça n'a pas d'importance, puisqu'à priori la base maître ne devrait pas être trop utilisée, c'est juste une sorte de "knowledge base" si j'ai bien compris). 
- puis je rejoins quand même Neige sur l'utilisation de la base, même si je ne suis pas vraiment pour les vues globalement : je pense plutôt à des droits; l'utilisateur "sur site" ne doit pas pouvoir mettre la base à jour, juste la lire. Le seul utilisateur autorisé à modifier les bases esclaves doit être accessible uniquement depuis la base maître, ou plutôt le script maître).

coockiesch · Answer

Salut Malalam et merci pour ta réponse!
  Le problème c'est que le script va être installé sur des serveurs que je contrôlerai pas et qui ne seront pas forcément connectés au net... D'où l'idée que la mise à jour puisse se faire par fichier... J'utilise un développement en PHP car c'est un langage productif et connu mais je sors du cadre d'une réelle application web...

Pour ce qui est de mon flag, je pensais que si le flag supprimé est à true, l'élément de la base de données n'est pas proposé à l'utilisation (n'apparaît pas dans les listes à choix, etc...). Ce qui permet une fausse suppression...

Raf

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

coockiesch · Answer

Je vais étudier tout ça, merci! :-)

Raf

La boîte à bouts de codes
"On dit que seulement 10 personnes au monde comprenaient Einstein. Personne ne me comprends. Suis-je un génie???"

Conception

10 réponses

Votre réponse

Discussions similaires