[RESOLU] Créer des objets pour toute ma base

Eléphant du PHP | 95 Messages

23 avr. 2014, 11:14

Bonjour à tous,

Une question simple mais nécessitant un peu d'expérience...
Je travaille en PHP Objet sur une base de donnée relativement importante de plusieurs Mo.
Mon application PHP ne réalise que des statistiques et potentiellement (au choix de l'utilisateur),
sur toutes les données présentes dans la base.
L'avantage de travailler avec des objets me permettrais (je pense 8-) ) de me décharger complètement des accès à la base,
en créant une fois pour toute, tous les objets au chargement de l'application.
Ma structure de classe serait en fait le reflet de ma structure de données, et plutôt que d'y générer les objets à la demande, je génère tout d'un coup.
Pensez-vous que c'est réalisable, qu'est-ce que cela engendre d'un point de vue problèmes de fonctionnement, bref voyez-vous des points noirs dans cette manière de fonctionner?
La b!te et le couteau sont bien souvent les meilleurs outils...mais aussi et surtout les seuls qui sont toujours à disposition!!

ViPHP
xTG
ViPHP | 7331 Messages

23 avr. 2014, 13:15

Moi j'y vois un problème, tu vas surcharger la RAM de ton serveur.
Si tu n'as qu'un utilisateur ça va, si tu en as plusieurs...

Le plus simple serait encore d'optimiser les requêtes SQL.
Voir mettre en cache les résultats des requêtes les plus courantes.

Eléphant du PHP | 95 Messages

23 avr. 2014, 14:43

Oui c'est bien ce que je pensais, le problème du cache c'est que je travail sur des données médicales sensibles et que je suis donc soumis tout comme l'application que je développe à la confidentialité...SSH et compagnie doublé d'un système de mise en cache 8-| je sais même pas par où commencer :oops: et dans la mesure où je n'ai que 6 mois je veux faire au plus simple.
Il y aura très peu d'utilisateur, une dizaine tout au plus, et rarement en même temps.
Je dispose d'un serveur dédié à l'application.

En fait il y a deux choses qui me tracassent un peu :-/
1- l'accès répétitif aux données de la base n'est pas une gêne en soit, non pas que les requêtes soient compliquées ou non optimisées, mais il y a vraiment beaucoup d'entrées. En gros c'est pas grave d'attendre un peu genre 10 ou 15 secondes, mais à chaque fois là ça devient casse-pied -_-
2- j'ai peur de me mélanger un peu les pinceaux, quelqu'un peut me confirmer? je voudrais partir sur du php objet, avec une base mysql. Idéalement, partir sur une architecture MVC pour l'application. L'interface utilise le contrôleur pour communiquer avec le modèle ou pour l'interroger, et elle se met à jour grâce au pattern Observer/Observable (ça existe en php ce truc?). Le modèle puise t-il ses données dans la base suivant s'il est ou non en possession des données, ou bien la base est elle interrogée directement par le contrôleur auquel cas modèle=base?

Mon idée de charger la base dans le modèle me permettrait donc de résoudre ce second problème!
Comment procéder pour occuper au minimum le serveur et donc le temps d'attente coté utilisateur tout en maintenant une architecture permettant à l'application d'évoluer, qui fait quoi dans tout ça?
La b!te et le couteau sont bien souvent les meilleurs outils...mais aussi et surtout les seuls qui sont toujours à disposition!!

ViPHP
xTG
ViPHP | 7331 Messages

23 avr. 2014, 16:01

Le côté confidentialité ? Que les données soient dans le cache du serveur ou bien dans la base de données il n'y a pour moi aucune différence.
Le cache n'est qu'une image des données à un instant T qui se trouvent au même endroit.
C'est juste un récipient plus rapide à interroger.

Je fais peu de POO donc je te répondrais surement par une bêtise, mais je ne pense pas qu'il y ait de problème pour ce pattern.

Regardes quelle taille de données tu as, combien de RAM tu as. Et combien d'utilisateur max en parallèle tu auras.
Tu sauras si stocker tout dans des objets est viable ou à jeter tout de suite à la poubelle. :)

Eléphant du PHP | 95 Messages

23 avr. 2014, 16:21

Le souci que j'ai avec la confidentialité est le suivant: ils s'agit de données médicales (résultats d'examen ect...) soumises au secret médical.
Un cache est si je ne me trompe pas accessible à tout le monde, contrairement à mes données qui ne sont visibles que par l'interface utilisateur protégée par par un système d'identifiant/mot de passe et elle-même connectée à ma base le tout sur un serveur sécurisé https. En tapant l'adresse du cache dans mon navigateur j'ai accès à toutes les données en contournant les protections mises en place exemple (même s'il n'y a pas de sécurité/danger ici c'est pourquoi je peux donner le lien): http://www.latortuefacile.fr/cache/index1.html.

Pour le reste je vais me pencher la dessus, je suis encore sur la conception papier mais je préfère anticiper :D
En tout cas merci pour tes conseils. Si d'autres sont prêts à intervenir, je suis preneur!!
La b!te et le couteau sont bien souvent les meilleurs outils...mais aussi et surtout les seuls qui sont toujours à disposition!!

Avatar du membre
Modérateur PHPfrance
Modérateur PHPfrance | 8758 Messages

23 avr. 2014, 17:56

salut,
En tapant l'adresse du cache dans mon navigateur j'ai accès à toutes les données en contournant les protections
heu normalement ce n'est pas donné à tout le monde cela.
et pourquoi ce cache serait il dans "l'espace web" ? (en clair tu peux très bien le mettre en dehors du "document root" du serveur.

parce qu'a partir de la tes données sont présente en base, c'est pas forcément plus compliqué d'aller directement à la source (surtout que les identifiant sont en clair dans le code ;))

Si tu as un durée d'execution des requêtes qui est de 10 ou 15s la question de l'optimisation se pose (index correct, modèle correct, requête qui ne fait pas des jointures foireuse etc etc) mais aussi du cache coté serveur de donnée afin.

Vu que tu n'as pas énormément d'utilisateur (cible) ce n'est pas sur l'infrastructure qu'il taper en premier.

si non, oui je radote :
- cache sgbd
- cache serveur web

le problème d'ajouter du cache c'est de gérer correctement la durée, son alimentation etc pour que la navigation soit fluid (si non imagine la tête du mec qui tombe sur le renouvellement du cache de 50Mo ;) )

@+
Il en faut peu pour être heureux ......

Eléphant du PHP | 95 Messages

24 avr. 2014, 12:44

Ok je vois....un cache faut que je regarde ça de plus près, mais la tout de suite j'ai quelques questions qui me viennent!!

Bon dans un premier temps je reprends et développe un peu plus pour plus de conseils,
- Une dizaine d'utilisateur :D
- Une centaine de requêtes prédéfinies avec ces utilisateurs
ex:
  • compter ou sélectionner les patients du service X entre date1 et date 2
  • compter le nombre de dipositif médicaux implantable utilisés par le médecin X entre date1 et date 2 pour les interventions de type Y
  • ...

- Environ une utilisation quotidienne par user... autant dire qu'à chaque fois qu'un user travail le cache ne sera plus à jour surtout si je me base sur un timeout lié à l'évolution des données.
- Les données évoluent (pour certaines) toutes les 5-10 minutes et (pour d'autres) 2 ou 3 fois par jour. Les statistiques réalisées servent au pilotage de la clinique dans laquelle je travaille, et ça c'est un besoin limite temps réél.
- Aucun utilisateur ne veut avoir besoin d'attendre pour afficher ses résultats.

Ma question:
- Un cache se met-il a jour tout seul sans qu'un utilisateur n’exécute de requête? 8-|

Je me demande toujours si c'est vraiment nécessaire, et dès que mon modèle sera terminé je ferais un post pour qu'on y voit plus clair ;)
En tout cas merci à vous.
En attendant voici un petit aperçu
La b!te et le couteau sont bien souvent les meilleurs outils...mais aussi et surtout les seuls qui sont toujours à disposition!!

Eléphant du PHP | 422 Messages

24 avr. 2014, 13:49

hello

pour le conseil , la solution la plus simple sera la plus efficace :) (perf + maintenance)

dans le sens ou si tu ajoute du load balancing du cache du HA du front end ... bas oué mais nan ca marchera pas :)

des requetes SQL optimisé (== précise, indexé, hash) permettront d'avoir de bonne perf

++


http://dev.mysql.com/doc/refman/5.0/fr/ ... cture.html
http://blog.nicolashachet.com/technolog ... -code-php/
http://fr.openclassrooms.com/informatiq ... de-donnees
http://fr.openclassrooms.com/informatiq ... veur-linux
toujours faire une recherche sur http://www.php.net et/ou sur http://www.google.fr :)
utiliser http://ideone.com/ pour vos codes :)

Mammouth du PHP | 571 Messages

24 avr. 2014, 16:18

- Les données évoluent (pour certaines) toutes les 5-10 minutes et (pour d'autres) 2 ou 3 fois par jour. Les statistiques réalisées servent au pilotage de la clinique dans laquelle je travaille, et ça c'est un besoin limite temps réél.
dans ce cas faire un cache pourrait s’avérer contre-productif quant au but recherché(performance) car cela suppose de vider le cache et de le régénérer à chaque opération d'ajout, d'update, de suppression des données ce qui est tout de même coûteux à faire toutes les 5 ou 10 mn.
Par contre écrire les requêtes les plus lourdes et les plus complexes(généralement celles qui comportent trop de jointures et trop de calculs) dans une procédure stockée Mysql pourrait se révéler très performantes car les requêtes sont stockées en permanence dans mysql.

Je ne sais pas si t'es obliger d'utiliser mysql mais MariaDA peut être un bon compromis si tu recherches la performance.
Sans oublier de faire les requêtes préparées ou d'indexer les colonnes qui permettent de trier, de rechercher...d'indexer aussi les clés étrangères.

Eléphant du PHP | 95 Messages

25 avr. 2014, 10:34

Pour qu'on soit sur la même longueur d'onde, voici un schéma du projet.
Un EAI (Jeebop) alimente ma base (BME stats) à partir des données saisies dans les autres bases via des application (il y a d'autres bases, pas uniquement celles du schéma), en gros c'est un super prog qui comprend toutes les données de toutes les bases et qui est capable de faire le lien entre des données hétérogènes. Il observe et alimente toutes les bases en temps quasi réel.

Il n'y a pas de requêtes d'insertion de données pour mon application de stats, uniquement de la sélection :!:

J'ai pas mal d'expérience avec MySQL, et pour avoir travaillé dessus, je sais bien qu'un modèle mal construit ça implique de la lenteur.
Le nombre d'utilisateur n'étant pas très important, je pense que ça suffit largement même s'il y a beaucoup de données.
Je pense que tu parles de MariaDB ( et non MariaDA :P )
Je ne vais pas remettre en cause ce choix, ça fonctionne pour énormément de monde et c'est suffisamment avancé pour être "rapide".
Je ne suis pas non plus à une ou deux secondes prêt.

Je pense que je vais comme l'a dit telnes utiliser
la solution la plus simple sera la plus efficace :) (perf + maintenance)
- Indexer les bonnes colonnes : dates, heures ou timestamp, les plus utilisées pour le tri ou la recherche comme yann18 le dit.
- les clés étrangères doivent être indexées, ça se fait tout seul non? une clé étrangère d'une table est la primaire d'une autre, et les clés primaires sont indexées automatiquement! faut -il indexer dans chaque table? à mon sens ça se fait tout seul en tout cas sous DBDesigner... et dupliquer les index alourdit le travail du SGBD!
- les requêtes préparées c'est bien dans le cas de requêtes répétées uniquement si j'ai bien compris et c'est un plus d'un point de vue sécurité en évitant les injections SQL

On s'est pas mal éloigné de ma question de départ, et j'ai maintenant de bonnes bases de départ.
Je met donc en résolu, mais si vous avez d'autres commentaires, ils sont les bienvenus, merci à tous!
La b!te et le couteau sont bien souvent les meilleurs outils...mais aussi et surtout les seuls qui sont toujours à disposition!!