Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1601 connectés 

  FORUM HardWare.fr
  Programmation
  Divers

  [conception] souci de choix pour une appli client/serveur

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[conception] souci de choix pour une appli client/serveur

n°1735526
silver87
Posté le 22-05-2008 à 10:33:41  profilanswer
 

Bonjour à tous.
 
Pour commencer, si vous trouvez que le titre du thread ne convient pas, n'hésitez pas à la dire.
 
Alors voilà : Je dois mettre en place une appli de gestion, qui sera utilisé en intranet (voir plus tard, toujours en intranet, mais sur plusieurs sites en france).
 
J'ai du mal à faire un choix sur la techno à employée. Le serveur actuel n'en est pas vraiment un (c'est un PC récent mais basique servant de serveur). J'ai peur qu'en faisant l'appli de type "site web" (PHP) qui tourne sur le serveur, et les clients s'y connectant, celà rame. Sachant, que comme c'est de la gestion, il y a gros d'accès à la base de donnée.
Côté mémoire, ça devrait aller, mais entre toutes les pages/modules et la BDD, vu ce que ça demande en accès disque, ça pose problème.
Deplus, le côté PC et non serveur me fait avoir des doutes sur le multithreading (si à terme j'ai 20, 30 ou plus de personnes travaillant sur l'appli simultanément).
 
Par rapport à ça donc, je me demande si il ne vaut pas mieux que je passe par une appli type java (ou autre techno, si vous pouvez m'éclairer, ce serait avec plaisir, je ne peux choisir que du gratuit) tournant sur chaque client, le serveur servant uniquement pour la BDD.
Après reste à voir si on met à jour en direct sur le serveur, ou si on passe par des tables intermédiaires sur les clients, avec mise à jour du serveur 2 fois par jour ou plus.
 
J'oubliais, en plus de l'impératif financier, j'ai un impératif de temps (ce qui m'avait aussi poussé sur PHP/mysql) qui est de 3 mois max (la BDD sous Mysql est prête)
 
Sans vouloir être chiant, une explication (le minimum syndical  ;) ) avec vos réponses est souhaitée. Ce n'est pas un exercice de cours ou autre, et je suis le seul dev dans la boîte.
 
Merci d'avance, et bonne journée,
 
Cordialement.
 


---------------
mon feed HFR ; mon feed Ebay
mood
Publicité
Posté le 22-05-2008 à 10:33:41  profilanswer
 

n°1735530
skeye
Posté le 22-05-2008 à 10:48:01  profilanswer
 

Pour des questions de simplicité de déploiement je m'orienterais vers du web quoi qu'il arrive, un client lourd rendrait la tâche plus complexe à ce niveau. A moins bien entendu qu'il y ait des choses vraiment complexes à faire au niveau de l'interface utilisateur.
 
Niveau charge, php est loin d'être très lourd, et une 20aine d'utilisateurs ce n'est pas excessivement violent - ils passeront je suppose en moyenne quelques secondes sur chaque page, donc à moins d'avoir des scripts très lourds pas de soucis...difficile d'évaluer si c'est raisonnable ou pas sans pouvoir évaluer la charge engendrée par l'appli...
 
...et pour finir un serveur c'est jamais qu'un pc avec un peu de redondance pour sécuriser le truc, en général...[:joce]


---------------
Can't buy what I want because it's free -
n°1735547
silver87
Posté le 22-05-2008 à 11:12:20  profilanswer
 

merci.  
 
pour le serveur, y'a quand même des machines plus ou moins orientées pour faire que ça sature/rame le moins possible.
 
au niveau charge. nous sommes dans la gestion de stagiaires (entreprise de formation) avec la facturation des clients. Plus exactement c'est pour le suivi pédagogique des stagaires
 
les pages auront en moyenne entre 10 et 20 champs, avec autant de requêtes. Rien que pour le stagiaire, j'en suis à 4 pages différentes.
 
Au contraire, ils passeront un minimum de temps par pages (pour les mises à jour ou création de dossier). pour la consultation, ça dépend. Sachant qu'ils auront la possibilités d'afficher à peu près tout ce qu'ils veulent (donc autant de requêtes à paramètres à prévoir. rien que pour une sseion de formation donnée il y en a quelques unes)
 
après il y a la gestion des clients (facturation), la sortie de documents diverses (factures, convention, planning et j'en passe).
 
il y a divers degré d'accès et de fonctionnalités, selon si les clients sont des formateurs, directeurs, assistante, commerciales etc...
 
l'entreprise risque de s'agrandir, et on risque dans un futur très proche d'avoir 2 sites en france fonctionnant dessus. donc le nombre d'utilisateurs au final n'est pas fixé, et je préfère voir un peu plus large qu'il n'y a besoin tout de suite, on ne sait jamais

Message cité 1 fois
Message édité par silver87 le 22-05-2008 à 11:17:09

---------------
mon feed HFR ; mon feed Ebay
n°1735558
skeye
Posté le 22-05-2008 à 11:25:45  profilanswer
 

silver87 a écrit :

merci.  
 
pour le serveur, y'a quand même des machines plus ou moins orientées pour faire que ça sature/rame le moins possible.


 
Pas vraiment. il y a des machines plus ou moins puissantes, avec plus ou moins de processeur/ram, c'est tout. La seule vraie différence des serveurs c'est la redondance / la sécurité au niveau matériel.
Après c'est l'OS qui fait le boulot.
 
 

silver87 a écrit :

au niveau charge. nous sommes dans la gestion de stagiaires (entreprise de formation) avec la facturation des clients. Plus exactement c'est pour le suivi pédagogique des stagaires
 
les pages auront en moyenne entre 10 et 20 champs, avec autant de requêtes. Rien que pour le stagiaire, j'en suis à 4 pages différentes.
 
Au contraire, ils passeront un minimum de temps par pages (pour les mises à jour ou création de dossier). pour la consultation, ça dépend. Sachant qu'ils auront la possibilités d'afficher à peu près tout ce qu'ils veulent (donc autant de requêtes à paramètres à prévoir. rien que pour une sseion de formation donnée il y en a quelques unes)
 
après il y a la gestion des clients (facturation), la sortie de documents diverses (factures, convention, planning et j'en passe).
 
il y a divers degré d'accès et de fonctionnalités, selon si les clients sont des formateurs, directeurs, assistante, commerciales etc...
 
l'entreprise risque de s'agrandir, et on risque dans un futur très proche d'avoir 2 sites en france fonctionnant dessus. donc le nombre d'utilisateurs au final n'est pas fixé, et je préfère voir un peu plus large qu'il n'y a besoin tout de suite, on ne sait jamais


 
 
J'ai pas l'impression que ce soit une appli particulièrement lourde ou complexe que tu décris là...à part qu'à développer en 3 mois tout seul c'est pas forcément gagné si tu dois tout livrer d'un coup. Oriente-toi vers la plate-forme/le langage que tu maitrises le mieux...


---------------
Can't buy what I want because it's free -
n°1735567
silver87
Posté le 22-05-2008 à 11:33:04  profilanswer
 

effectivement, ce n'est pas très complexe. Seul c'est un peu plus hardu, oui.
 
pour la lourdeur, je ne sais pas vraiment, donc j'aurai tendance à faire confiance à ce que l'on me dit.
 
merci pour ta réponse.


---------------
mon feed HFR ; mon feed Ebay

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Divers

  [conception] souci de choix pour une appli client/serveur

 

Sujets relatifs
client-serveur UDP probléme de communicationmysql command line client -- probleme d'accent
Installer Apache sur un serveur avec IISProblème de droit copie d'un serveur à un autre
Lancement appli PHP avec xamppnouveau souci dsl
[C] Connection à un serveur mailSouci taleaux en php...je galère!
client-serveur probléme 
Plus de sujets relatifs à : [conception] souci de choix pour une appli client/serveur


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR