Discussion :

[73672]

Bonjour,

J'aimerai avoir votre avis sur un problème de conception.

Nous avons une application complexe qui tourne sur un serveur et dispose d'une base de données. Technologies utilisées : PHP et MySql

Cependant cette base de données est la plupart du temps mise à jour en local.

Mon problème, mettre à jour la base de données serveur avec celle locale, sachant que la mise à jour de la BD n'est pas critique, même si une mise à jour quotidienne serait intéressante.

Voici les solutions qui s'offrent à moi :
- Lorsqu'une requête est effectuée en local. l'effectuer aussitôt sur le serveur. D'après moi pas intéressant car la mise à jour à la seconde n'est pas essentielle.
- Effectuer en batch chaque jour une copie de la BD locale et la charger sur le serveur. Solution lourde car la base de données sera importante et celà oblige à charger des données qui n'ont pas évolué.
- Enregistrer les requêtes effectuées en local dans un fichier log. Lors d'un batch, effectuer les requêtes dispos dans le fichier sur le serveur puis purger le contenu du fichier log local.

De mon point de vue, la dernière solution me semble la meilleure.

Qu'en pensez vous?

Savez-vous si MySQL permet de logguer automatiquement les requêtes où dois-je coder cette fonctionnalité?

[SQLpro]

autre solution, plus légère et plus automatique : ajouter à chaque table deux colonnes de marquage : un GUID et un tag de mise à jour (I, U, D). Faire passer un batch qui régulièrement calcule les données différentielles et met à jour la base distante.

ALTER TABLE ...
ADD COLUMN TAG_VERSION CHAR(36) DEFAULT GUID ()
ALTER TABLE ...
ADD COLUMN TAG_SQLORDER CHAR(1) DEFAULT 'I'

Le GUID sert à versionner la ligne,
le Tag sert à savoir quelle ordre a été effectué : I => INSERT, U=> UPDATE, D=> DELETE.

Si I alors insertion dans table distante et update du I en U.
Si U et version <> alors mise à jour dans la table distante
Si D alors suppression dans la table distante et suppression finale dans table origine.

Tout cela peut être fait de manière très simples par des triggers hélas pas encore disponible sous MySQL !

A +

[73672]

Merci pour ton point de vue.

Celà dit je reste perplexe.

En effet celà m'oblige à calculer les données différentielles, j'ai peur que ça soit un traitement lourd si la base devient importante et si peu de données sont modifiées.

Un autre membre du forum m'a également proposé de rajouter un champ 'mise à jour' aux tables afin que chaque ligne possède la dernière date de mise à jour.

Celà me permettrait de sélectioner les lignes qui ont été ajoutées ou modifées avec une date>= à la date de dernière mise à jour des données serveur(date que je conserverai alors sur le serveur) puis de mettre à jour ces lignes sur le serveur.

On pourrait également faire un mix de vos 2 solutions : le tag qui indique la modif effectuée(I,U,D° ainsi que la date de dernière modif.

Cependant après réflexion, je persiste à croire que la solution consistant à logguer les requêtes dans un fichier SQL local, à mettre à jour la BD serveur à partir de ce fichier et à viderce fichier en local est la moins couteuse en temps de traitement est n'est pas moins souple que les autres solutions.

Mais je reste ouvert à la discussion si tu vois des désavantages à ma solution, n'hésites pas à m'en faire part.

A++

[romeo9423]

Bonjour,

J'aimerai avoir votre avis sur un problème de conception.

Nous avons une application complexe qui tourne sur un serveur et dispose d'une base de données. Technologies utilisées : PHP et MySql

Cependant cette base de données est la plupart du temps mise à jour en local.

Mon problème, mettre à jour la base de données serveur avec celle locale, sachant que la mise à jour de la BD n'est pas critique, même si une mise à jour quotidienne serait intéressante.

Voici les solutions qui s'offrent à moi :
- Lorsqu'une requête est effectuée en local. l'effectuer aussitôt sur le serveur. D'après moi pas intéressant car la mise à jour à la seconde n'est pas essentielle.
- Effectuer en batch chaque jour une copie de la BD locale et la charger sur le serveur. Solution lourde car la base de données sera importante et celà oblige à charger des données qui n'ont pas évolué.
- Enregistrer les requêtes effectuées en local dans un fichier log. Lors d'un batch, effectuer les requêtes dispos dans le fichier sur le serveur puis purger le contenu du fichier log local.

De mon point de vue, la dernière solution me semble la meilleure.

Qu'en pensez vous?

Savez-vous si MySQL permet de logguer automatiquement les requêtes où dois-je coder cette fonctionnalité?

Question bete mais pourqoi au moment d'effectuer ta requete en local tu l'effectues pas aussi a distance ?

[73672]

Question bete mais pourqoi au moment d'effectuer ta requete en local tu l'effectues pas aussi a distance ?

Si le serveur n'est pas accessible à ce moment là, j'ai peur que ça pose problème.

[73672]

Ben tiens pour ce qui rechercheront pareil que moi, MySQL a cette fonctionnalité :

http://dev.mysql.com/doc/mysql/fr/replication.html

Par contre, il faut avoir accès à la config du serveur local ainsi qu'à celui distant.