Bonsoir tout le monde!
Je suis actuellement en train de monter un projet et plus particulièrement de construire un cahier des charges pour une application client/serveur cependant je ne sais pas quel language de programmation choisir. Je maitrise très bien le Php mais c'est tout...
Ainsi voilà quelque critère pour mon application:
_Deux interface client/serveur
-->interface client sur Windows
-->interface serveur sur Linux
 
_L'interface client(local):
-->module de mise à jour automatique
-->gestion de flux html
-->interface graphique minime mais besoin par exemple d'une icone en barre de tache et pas besoin de fenetre "classique" (pas besoin du cadre bleu windows qui entoure la fenetre par exemple)
-->aucunne communication avec le matériel (sauf souris clavier)
-->poids léger
-->Aucune machine virtuel
 
_L'interface serveur(à distance)
-->fait appel à une base de donnée MySQL
-->permet d'effectuer des log: temps de connection client, etc...
 
_Divers:
-->Simple de maintenance
-->Pas de limite ou du moins pas beaucoup
 
Voilà j'espère avoir détailler au maximum mon projet qui vous permettra de m'orienter vers un language spécifique
A noter que mon projet est assez petit...
 
Voilà je vous est tout dis
Merci d'avance !

Personne pour m'aider ???

est ce que tu as vraiment besoin du client local  , est ce que tu ne peux aps le faire en php + javascript ( eventuellement avec un mini service qui ne servirai qu'a lancer la page web )  
 
pour le serveur, c'est au choix, tous les langages permettent de faire ce que tu a fait

c'est pas pour faire une borne publique ça ?
 
si oui, y'a un vieux topic ici (cherche) qui demandait un peu la même chose.
 
Opéra de mémoire a tout ce qu'il faut pour travailler en mode plein écran et de façon très limitée, justement pour une borne publique (pas de click droit, etc.)

PHP ca n'est pas pour le client serveur mais pour les applications web.
 
Pour faire ton application Client serveur de nombreuses technologies sont possibles, comme par exemple Java, DotNET, etc mais le client /Serveur ca n'est pas pour les débutants car il faut que tu connaisse bien le langage et aussi les SGBD, donc ca ne s'apprends pas en 2 semaines.

Et une appli web ne fonctionne pas sur une architecture client-serveur peut être ?

merci de me l'avoir appris  
 
sinon, je vois pas le rapport entre client serveur et SGBD, peux tu m'eclairer ?  
 
merci  
 
florent  

Je te cite :
 

 
MySQL n'est pas un SGBD ?  
 
 
Quand on dit application Client/Serveur ca peu vouloir dire plusieurs choses différentes selon le contexte. Dans ton contexte je pense que ca s'entends par Serveur (la ou est le SGBD) et Client (la ou s'éxécute l'application).

MySQL n'est pas un SGBD, ça se saurait. Oracle par contre oui.
C'est Harko qui me l'avait expliqué en détail à l'époque, il m'a tout appris.

 
 
Tu sais si tu utilises sous MySQL des tables innoDB tu as meme les "transactions" sous MySQL... Alors langage SQL + transactions ca ressemble fort à un SGBDR.... Je comprends que MySQL sans les transactions ca choque pour les "puristes" des SGBD, mais dans certaines applications web ou tu a spas besoin d'une super sécurité (un forum par exemple), c'ets quand meme super intéréssant, parce que ayant les transactions débrannchées, mysq sans les trasactions bat tous les autres SGBD qui ont les transactions par défaut en performances pure, d'ou son utilisation massive pour les sites Web amateurs par exemple.
 
Donc effectivement s'il veux faire une application "Pro", il doit utiliser les transactions, donc soit MySQL en mode transactions avec Innodb, soit un autre SGBD.
 
Quoi qu'il en soit ca "sert" de SGBD, mais même s'il utilise un autre SGBD la question reste la même...

InooDB c'est pas performant.

le R de SGBDR n'est pas pour tRansaction, mais pour Relationnel ( comme dans algèbre relationnelle)...  
Une base de donnée hierarchique avec des transactions n'est pas relationnelle.

 
Comparé à MySQL sans les transactions, c'est forcément plus lent puisqu'il doit gérer les transactions en plus, donc avec des écritures disques en plus.
 

 
Oui je sais et alors ?
 
 

On compare pas InnoDB à MySQL malheureux...  

   J'avais pas vu ça

 
Oui bah c'est nul donc, c'est pour ça que Harko m'a toujours dit que Oracle c'était mieux.

quid d'ingres ? libre maintenant depuis quelques années !

Les bases libres c'est de la merde...

 
Tu ne semble pas comprendre que tu peux utiliser des tables InnoDB DANS MySQL et donc gérer les transactions sous MySQL.
 
Pour le reste si tu veux comparer MySQL avec d'autres SGBD amuse toi, tu peu en faire un sujet potentielement très long, mais ca n'est pas du tout la question posée par "analfabete"
 
 

 
Même en utilisant la version gratuite d'Oracle, Oracle prends beaucoup plus de ressources sur le serveur (Ram par exemple) que d'autres produits, comme par exemple MySQL, PostGreSQL et FireBirdSQL.
 
 
 
 

waouh... comment t'es trop fort !
   
 
http://dev.mysql.com/doc/refman/5. [...] gines.html

 
Oui non mais là tu compares des bases "jouets" à un SGBD professionnel

Moi ce qui m'interesserait c'est de savoir en quoi la consommation de RAM est un indicateur de perfomances. D'avance merci.

Si le R de SGBDR signifie effectivement "relationnel", il signifie aussi, implicitement, transaction.
 
Effectivement, pour qu'un SGBD soir effectivement relationnel, il ne faut pas qu'il se contente de stocker et savoir relire des données hiérachisées/suivant des règles. Il doit aussi, et ça fait partie de la définition d'un SGBDR, garantir à tout moment la cohérence des relations entre les données.
Seul un système de transaction permet un tel niveau de garantie.

 
Ca à surtout à voir avec la ram dont tu dispose sur le serveur, si tu as un serveur dédié avec 500 meg de ram ca ne sera pas suffisant pour Oracle, le serveur va swapper en permanence, alors que MySQL peu tourner sans probleme...
 
Les serveurs dédiés à 500 Mo de RAM ne sont pas tout à fait au même prix que les serveurs dédiés à 2 Go de RAM...    

+1
 
d'autant que la montée en charge d'Oracle, contrairement à beaucoup d'autres produits, n'est même pas linéaire : entre 1 et 100 transactions concurrentes, la charge est à peine multipliée par 2 (bon, après, comme tout le monde, ça fini par devenir exponentiel, mais tout est une question de limites matérielles)

jamais dit le contraire, je réagissais à cette affirmation  

Je peux très bien te sortir une base avec 1000 tables, sans relation et avec des redondances dans tous les sens, faire mes requêtes avec des transactions, c'est pas pour ça que j'aurais une base relationnelle

anapajari, Le rapport avec la question initiale ?
 
Pour les "discussions générales" sur les SGBR je me demande si ce sujet sur les SGBD ne serais pas plus adapté...
 
 

 
 
Criminel !

Qu'est ce que tu appeles serveurs dédiés? Les machins fournis par des hébergeurs? Je vois pas ce que ça vient faire la dedans.
Sinon la différence entre un serveur ( la machine ) avec 500Mo de RAM et 2Go c'est grosso-modo 300€ ( au prix de la RAM en ce moment)

Aucun... D'ou ma surprise quand tu as commencé tes leçons sur le fonctionnement d'innoDB
 

[moment blog]Roumanie's power ... [/moment blog]

Nous n'avons aucune indication sur la façon dont son projet sera "hébergé"... Ni aucune indication sur le matériel dont il dispose...
 
Nous savons par contre qu'il à indiqué que cela serais fait en MySQL    

analfabete : tu vas avoir du mal à trouver ici autre chose que des trolls en furie, alors voici un début de réponse potentielle : ça dépend de plus de choses que ça, notamment de tes délais, de l'objectif de qualité que tu veux atteindre (application "juste pour tester" ou destinée à être mise à disposition au public ?), et des personnes disponibles.

Si tu as peu de temps et que c'est toi qui le fera, tu peux le faire en php/mysql (choix le plus simple pour toi à priori).
Si tu as plus de temps (genre beaucoup) tu peux essayer d'apprendre une autre technologie (genre interface flash ou application windows), mais personnellement, si tu as un objectif de qualité, je te déconseille.
Si c'est quelqu'un d'autre qui le fait, tu as le choix, en fonction des compétences du développeur : interface windows (application "classique" ), flash, director, simple page web... Du côté du serveur, tu peux utiliser n'importe quelle technologie pour te connecter à la plupart des bases de données, donc tu peux parfaitement faire une interface d'administration en php, par exemple.

http://www2.sqlonrails.org/
Une vision à part.

bonjour,

merci de votre attention, et passez une meilleure journée que celle qui s'annonce pour moi

 
Ca fait + de 200 ans que les privilèges ont été abolis faut se mettre à la page !

vu la tronche d'Oracle et son ergonomie, ça se tient