[Conseil]Language web pour site web lourd

Statut
N'est pas ouverte pour d'autres réponses.

Calvin80

Respect is key
oui gus je comprends bien ça..
mais dans le cas ici, la DB n'est utilisée que pour le site..
SI on parlait d'un serveur de DB (comprendre "1 serveur, plusieurs machine cliente") OK, mais séparer deux machine pour faire une relation '1<->1'... je suis pas convaincu (je me trompe certainement...)

Sans le servie web, sa machine DB ne consomme rien...

Dans le cas présent, je ne suis pas persuadé que mettre le db sur la meme machine que le service soit pénalisant (à moins que le service prennent vraiment 100% des ressources machines, ce qui m'etonnerait..), mis à part le fait quand va augmnter le temps de réponse en séparant la DB sur une machine distante...

A moins que la DB servent de données pour plusieurs services sur plusieurs machines, dans ce cas je comprends l'interet de créer un vrai serveur de DB.
 

guslinux

Gamerz'ien
Calvin80 a dit:
oui gus je comprends bien ça..
mais dans le cas ici, la DB n'est utilisée que pour le site..
SI on parlait d'un serveur de DB (comprendre "1 serveur, plusieurs machine cliente") OK, mais séparer deux machine pour faire une relation '1<->1'... je suis pas convaincu (je me trompe certainement...)

Sans le servie web, sa machine DB ne consomme rien...

Dans le cas présent, je ne suis pas persuadé que mettre le db sur la meme machine que le service soit pénalisant (à moins que le service prennent vraiment 100% des ressources machines, ce qui m'etonnerait..), mis à part le fait quand va augmnter le temps de réponse en séparant la DB sur une machine distante...

A moins que la DB servent de données pour plusieurs services sur plusieurs machines, dans ce cas je comprends l'interet de créer un vrai serveur de DB.
Tout dépend des requetes exécutées.
Avec PostGres il est possible de réaliser de la logique à l'aide de fonctions. En gros, php communique des infos au serveur BDD, et c'est le serveur BDD qui choisis l'action à réaliser (Insert,Update ... cascading etc). Tu peux aussi te retrouver avec des sous requetes, des tables virtuelles etc..

Théoriquement - je n'ai jamais pu le vérifier par moi meme (j'espere quand meme pouvoir le faire un jour) - si on réparti la logique de cette manière, on réparti la charge de calcul par la même occasion.

Actuellement lors de mes développements en php, je travaille avec trois niveaux :
  1. Gestion des accès aux resources,
  2. Gestion de l'affichage des informations,
  3. Gestion des sauvegardes et du chargement des infos.

Pour les deux couches inférieures, l'affichage envoies des informations à l'objet de donnée, et cet objet réalise les sauvegarde, les mises à jours etc...

Pour ce qui est de la partie sauvegarde des informations, ca serait drolement plus simple au niveau php si je ballancait les infos brutes au SGBD... après c'est au SGBD de faire le tri et de tout classer correctement.
 
Pourquoi pas une tâche Ant ?

Je veux dire :
Dans ta demande initiale tu parles de faire un calcul sur base de requêtes SQL pour afficher le résultat dans une bannière visualisable par un grand nombre de personnes...

Se pourrait-il que les "données" dans ta base de données ne soient pas mis à jour "constamment" mais plutôt à intervalles réguliers mais "espacés" (genre toutes les heures, une fois par jour, une fois par semaine etc) ?

Alors une tâche Ant pourrait lancer un script pour réaliser tes requêtes et générer un document XML contenant les résultats. Le fichier XML serait ensuite transformer par une feuille XSL (via un processeur de transformation XSLT) pour former un document HTML "statique" avec du Javascript par exemple.

La page HTML serait ainsi mise à jour quand les données de la base sont modifiées (il faut donc prévoir dans 'quelles conditions' il est judicieux de "prévenir" qu'une modification a eu lieu et donc de lancer la tâche Ant).
 

Bingo

Beer Addict
TITM4v3rick a dit:
Pourquoi pas une tâche Ant ?
Pour ce genre de régie publicitaire (si c'est bien ce en quoi ça consiste), il faut mainntenir des statistiques de bannières affichées (ça implique du code côté serveur d'une façon ou d'une autre), et surtout des statistiques de clics (le lien de la bannière pointe sur le serveur qui met à jour les stats et redirige vers le "vrai" lien).
Ca ne me paraît pas compatible avec un site statique.
 
Statut
N'est pas ouverte pour d'autres réponses.
Haut