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

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.

---

Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

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

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).

---

Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

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...

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...

---

Neige

N'hésitez pas à lire la doc de PHP avant de poser des questions triviales...

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

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).

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