Reprise du message précédent :
Mon prof ma parlé de la possibilité de faire un script en PHP qui ouvre les tables côtés serveurs et clients ET qui exporte les données

Si on fait un dump regulierement depuis les PC clients vers la BDD du serveur ? Ca peut fonctionner ?

si tu connais la notion de clé primaire / étrangère dans un bd, tu vas vite comprendre pourquoi l'opération de synchro entre la bd du serveur et celles locales aux pc clients va poser un problème assez chaud à résoudre
 
On te dit depuis le début que le réseau est ce qui tombe le moins en panne (ou que c'est facile à le rendre robuste). Donc, optes pour la solution client-serveur.

Je prefere cette solution mais le tuteur ne veut pas ...
On ma dit qu'il est possible d’écrire un script PHP sur chaque PC clients qui renvoi les données vers la BDD en réseau ?

 
T'es en train "d'inventer" le client/serveur à l'envers mais t'auras toujours le pb de la synchro.
 
Présentes la solution en termes de chiffres. Quand on commence à parler pognon aux décideurs, en général, là, ils comprennent pourquoi telle solution technique est réellement mieux Et ils laissent tomber leurs idées à la con.

Il y a pas mal de facon de faire la synchro, mais comme on t'as déjà dit ca depend beaucoup de la facon dont l'appli fonctionne, peut etre qu'exporter les tables ce ne sera pas suffisant.
 
Quid des probs d'integrité referentielle?
Quid des conflits entres plusieurs PC client qui importent en meme temps ou les meme données?
Quid des conflits de données identiques modifées par deux clients en meme temps?
 
Imagine un cas super simple, une DB avec une seule table, deux champs et deux PC.
 
Table1:
ID int
Valeur varchar(xxx)
 
Tu veux synchro ta table des clients vers le serveur.
Tu exportes la table des clients et tu l'envoi dans la DB server.
 
sur le PC1 ta table c'est:
1    Valeur1
2    Valeur2
3    Valeur3
 
Sur le PC2 ta table c'est:
2    Valeur7
3    Valeur1
4    Valeur4
5    Valeur2
 
Comment tu fais pour inserer ca dans la table du server?
Comment tu sais que l'ID 2 doit avoir comme valeur Valeur2 et pas Valeur7?
Qui te dis que l'ID 2 du PC1 est la meme que l'ID 2 du PC2? Peut etre que tu dois garder les deux valeures.
 
T'as déjà des problemes avec le cas le plus simple du monde, tu peux ajouter de l'integrité referentielle au dessus pour faire un x100 a la complexité.
Je suis sur que ton aplpi n'utilise pas qu'une table et que deux PC et qu'il y a de l'integrité référentielle.
Il y aurai moyen de la faire tourner mais il faudrai aussi réécrire l'appli pour prendre en compte certains problemes et eviter de faire certaines choses pour faciliter les synchro, on parle d'une réécriture complete de l'appli avec un redesign de la DB.
 
Demande a ton prof si c'est ce qu'il a prévu.
 
Il ya une bonne raison pour que le monde entier utilise une infra client/server.

Par contre, ce que tu peux faire, c'est un sgbd en maître/esclave, avec 2 esclaves. Si l'un des 2 tombe, t'as toujours l'autre qui sera identique au premier et prendra le relai.

Ca existe en MySQL ca?

Je n'ai pas bien compris le problème avec les clés pour les deux PC ; Pour l'ID 2, pourquoi on aura pas valeur 2 et valeur 7 ?

Parce qu'un ID est unique. Si t'avais étudié les BD relationnelles, tu le saurais

 
Depuis mysql 5, oui, le maître/esclave est possible (facilement, à ce qu'il paraît, j'ai jamais testé perso). Tu peux même faire du cluster

Il est possible de mettre combien d'esclaves pour un maitre ?

Et en cas de panne du serveur maitre, on doit modifier nos programmes qui utilisent la BDD (labview ....) pour qu'ils puissent se connecter vers la BDD esclave (@IP...), faire cela sur une quinzaine de postes ... ?

RTFM.

Je dis ca parce que si c'est vrai, je pense que mon tuteur va me dire que c'est pas interessant car en cas de panne les techniciens auront des modifications à réaliser ...

Tu dis à ton tuteur que le réseau, y'a peu de chance qu'il tombe en panne et que c'est plus facile de faire en sorte qu'il ne tombe pas en panne (rendre son architecture fiable et dispo h24) plutôt que de déléguer à l'appli la gestion de pbs dus au réseau.  
Sinon, tout ce que tu vas réussir à faire, c'est pondre une usine à gaz inmaintenable et qui aura probablement pleins de bugs/pbs dus à la synchro entre les bases des pc clients.

Donc tu pense qu'il serait mieux de mettre la BDD en réseau, si je sauvegarde regulierement les enrengistrements vers un disque réseau, il n'y a pas d'utilité à créer une replication maitre/esclave?

En prod, t'as la BD sur une serveur à laquelle se connectent tous les clients. La nuit (ou en heures creuses), tu fais tes opérations de maintenance planifiées (backup, entretien de la bd...).
 
A toi de voir si le maître/esclave a un intérêt.

Sinon, je mets la BDD en reseau (j'exporte les enregistrements vers un disque réseau) ET je laisse les BDD sur les PC (elles sont déjà installés) au cas où on aurait une panne réseau (il suffirait juste d'utiliser le lien ODBC déjà configuré vers la BDD local) ?  Parce que mon tuteur veut absolument qu'on puisse bosser au cas ou la BDD réseau ne soit plus accessible.

NON, pas de bd sur les postes clients, sinon, tu vas te retrouver avec le pb de synchro  

On tourne en rond la
 
On t'as donné notre avis, a toi de faire un choix.
Soit tu écoutes le bon sens et tu utilises une solutions tres robuste et testée par des millions d'appli (client/server), soit tu fais ton truc bancal sur les PC locaux.
 
Voila le liens vers les facon d'eviter les problemes dues a la panne d'un server: http://dev.mysql.com/doc/refman/5. [...] rview.html
 
Comme tu le vois il y a moyen d'assurer un 99.999% de disponibilité (ca correspond a 5mins d'indisponibilité par an), les PC locaux n'arriveront probablement meme pas a 95%...
 
Je ne sais pas ce qu'il te faux de plus comme preuve.
Ton tueur n'a pas l'air d'y connaitre quoi que ce soit mais il continue a te donner des mauvais conseils ... A toi de l'eclairer et de le convaincre qu'une db en reseau c'est la solution la plus simple et la plus fiable.

Oui je veux mettre la BDD en réseau ! Et configurer un lien ODBC sur les PC clients afin qu'ils puissent accéder à la BDD .
Mais je compte laisser le lien ODBC actuel qui pourra être utilisée au cas où (en secours afin que les techniciens continuent leurs mesures) ?
Je dois présenter cela à mon tuteur aujourd'hui ...

Ben laisser le lien en local ne me paraît pas une bonne idée, encore une fois, à cause du pb de synchro. Tu vas faire comment si 2 d'entre eux modifient qq chose en base, et comme par hasard, le même enregistrement
 
Si c'est un lien local que pour de la consultation, pourquoi pas, mais surtout pas pour de l'écriture

Mais le lien local serait à utiliser juste si le reseau ne fonctionne pas (quasi jamais)

 
Uniquement en LECTURE, sinon, tu vas avoir le pb de SYNCHRO, je te dis. Si tu n'as pas de solution pour résoudre le cas simple que je t'ai énoncé dans mon précédent post, faut pas permettre aux utilisateurs de modifier les données de leur BD locale  

Je compte installer la BDD sur un serveur (+ le serveur WEB pour les formulaires). Préparer un autre serveur (installer serveur WEB identique et un serveur MySQL), ainsi en cas de panne, je n'aurai plus qu'a importer le back up et donner l'IP du serveur en panne au serveurs secours.
Bonne solution ?
Merci,

Oui c'est un bon début.
N'oublie pas de régulierement (tout les 2-3 mois) tester la procedure de backup/restore et de changement d'IP.
D'abord pour voir si tu as tout ce qui faut pour le faire et aussi pour te donner une idée du timing précis.
Plus tard tu pourrais meme envisager un script pour faire ca plus rapidement voir meme automatiquement.

Non leur besoin c'est un BDD centrale avec n BDD locale. Comme on peut le faire par ex. pour un supermarché ou chaque supermarché va avoir sa BDD locale qui est synchronisé avec la BDD centrale de l'enseigne.
 
Même si c'est 99% du temps du bullshit de faire des transfert de données dans tout les sens, c'est pas impossible à faire, ni loufoque.

C'est pas un soucis, n'importe quel SGBD correct va te synchro. deux BDD de lui même. Alors par contre bien sur c'est pas possible avec tout les SGBD et c'est pas un boulot de stagiaire, mais dans Oracle tout les outils sont là.
 
Par contre avec >20 licences Oracle ça va vite refroidir son tuteur.

OK, pour le script j'en ai déjà un qui permet de faire un back up (voir sujet SCRIPT dans PHP), puis sinon normalement ça ne prends pas beaucoup de temps pour remédier à la panne :
1/ Importer le dernier back up (qui sera sauvegarder sur le reseau ...)
2/ Attribuer l'IP du serveur en panne au 2ème serveur
Qu'est ce que tu voudrais rendre automatique içi ? (comme je suis en alternance, je voudrais laisser des consignes simples à suivre en cas de panne ...)
2ème question :
Ils y a environs 10 PC pouvant bosser avec la BDD, si je mets le serveur WEB (formulaires et exploitations des BDD avec des requêtes) et le serveur MySQL sur un même PC, ça tiendra bien ?
 
MERCI;

On utilise MySQL, le tuteur voulait cette solution mais on me la déconsseiller ... Tu en penses quoi ?
Merci;

 
On a jamais dit que c'etait impossible, juste hors de portée d'un stagiaire et une tres mauvaise idée pour un projet sans budget et aussi simple.
Evidement on peut faire pratiquement tout ce qu'on veut avec un SGDB mais c'est pas toujours une bonne idée d'envoyer les gens sur une piste alors qu'on sais qu'ils vont se vautrer.
 
Sinon le cas ici c'est une DB centrale avec les DB locale sur des pcs ... rien avoir avec un supermarché ou tout est sur des servers et probablement synchro/repliqué avec des appli pensée a la base pour etre répliquée (ou du moins la synchro a ete faite par des gens qui ont une bonne connaissance du sgbd et de l'appli).
 
De la synchro facil et pas cher d'un soft lambda pas créé pour ca, ca releve du miracle...

 
Pas un soucil?
Essaye de synchro n'importe quelle appli (avec une preference pour une appli faite pour tourner quasi seule sur la DB) en MySQL et puis on verra si tu trouves toujours que c'est pas un soucil ...
 
Evidement que c'est plus facil avec Oracle (ou meme SQL Server), c'est pas non plus le meme ordre de prix.
En SQL Server on peut repliquer facilement une DB vers plusieurs servers en 5 clics, mais ca coute 25.000€ par CPU ...

Non mais on peu aussi faire une analyse et proposer des solutions alternative telles que :
 
- si cnx(serveur) == OK => db = serveur, sinon db = locale
- si db locale != vide, alors affichage script PHP de soumission de donné avec l'utilisateur qui choisi d'envoyer ses données ou non et qui résous les conflit.
 
De base vous ne repondez pas au besoin du client puisqu'en cas de panne de la BDD serveur il n'y a plus aucun fallback si on reste dans du basique client-serveur.

J'ai pas très bien compris .... sinon, on m'avait dit qu'il y aurait des problèmes au niveau des ID ;

Faut voir le volume de données pour le diff. D'ailleurs SNY7, quel est le volume de données à traiter par jour (par exemple) ?

Pour un champ en clé primaire (pas de NULL autorisé) ou index unique (clé primaire AVEC NULL autorisé une fois) dans une table donnée, il ne peut avoir 2 valeurs identiques.

Donc je reste sur la solution serveur mysql/apache et un 2eme serveur secours (back up 1er serveur) en modifiant l'IP ?
Pour le volume de données, je ne sais pas mais il y en a beaucoup (une table a 61000 lignes ...).
Sinon niveau hardware, un PC normal ne suffirait pas à supporter les connexions vers la BDD et le site WEB interne ?
Merci.

En tant que serveur DB/Web, oui, pour une dizaine d'utilisateurs, pas forcément besoin d'une bête de course pour un formulaire web utilisé par 10 personnes en simultané, après tout dépend quand même du flux de données vers la base (genre je te balance 10000 enregistrements à faire multiplié par 10 personnes en même temps. )

J'ai cru comprendre que c'était des techniciens qui faisaient des mesures, voir si la saisie est humaine ou si c'est l'envoi automatique de gros fichiers de mesures

La majorité des résultats sortent directement de Labview vers la BDD) et certains avec les formulaires que j'ai mis en place.

Le plus simple reste de loin de définir un des pc comme étant un serveur contenant la bdd et de connecter tous ce beau monde dessus en plus le jour où tu rajoutes un pc c'est bcp plus simple

Puis de toute façon, je peux laisser un lien ODBC secours sur chaque PC à utiliser au cas où on aurait une maintenance réseau par exemple. Car si la BDD n'est plus accessible, on ne peut plus faire de mesures.