Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 15 sur 15
  1. #1
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut Généralités sur les ORM

    Bonjour à tous.

    J'ai une question qui me turlupine depuis que j'utilise l'ORM de Kohana (qui est un Framework).
    Jusqu'à lors je ne l'utilisais pas (module non activé), donc ça allait.

    Mais posons directement la question :
    Est-il normal d'être obligé de créer des clés primaires auto_increment (un seul champ en faite) sur toutes les tables ?
    En somme, de mettre des champs "id" partout.

    Avec Kohana ça m'a l'air d'être le cas, car en passant par l'ORM, il m'est (apparemment) impossible de mettre à jour une table ayant une clé primaire double zone, donc avec 2 champs.
    Genre table "articles_lang", clé primaire : (id_article, id_lang)


    Ou alors j'aurais raté un truc par là ?
    Ou serait-ce une spécificité (contrainte) propre à Kohana ?


    Autre question (accessoirement), quelle serait la meilleur convention de nommage pour les noms des champs ?
    Est-il mieux nommer id_article ou plutôt article_id ?
    (pour les clés étrangères par exemple)

    Concernant l'ORM Kohana, ça n'a pas vraiment d'importance, mais en voyant le fonctionnement, ça tendrait plutôt vers : article_id
    En faite on obtient quelque chose comme lors d'une jointure (pour exemple) :
    article_lang->id et article_lang->article->id


    Merci pour tout éclaircissement
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  2. #2
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    C'est la misère

    Pour les up, je sais que c'est pas bien ... (pas taper )

    Je sais aussi que Kohana c'est pas un FW très connu/utilisé, mais pour ce qui est des autres qui on des ORM, permettent-il d'avoir des clés primaires doubles, triples, ... ?
    Ou est t'ont obligé de créer une clé unique auto_increment sur chaque table ?


    Apparemment Kohana à une propriété $_primary_key, et on ne peu pas mettre autre chose qu'une chaine, donc 1 champ.
    Je m'attendais à pouvoir mettre un tableau pour plusieurs clés.
    Du coup si je fais un Objet->create() ça va insérer selon la valeur d'1 table (la clé).
    Si la table a une clé double par exemple, et bien ça n'ira pas.


    Est-ce un comportement normal selon vous ?
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  3. #3
    Responsable Développement Web

    Avatar de FirePrawn
    Homme Profil pro Sébastien Germez
    Ingénieur réalisateur
    Inscrit en
    mars 2011
    Messages
    3 158
    Détails du profil
    Informations personnelles :
    Nom : Homme Sébastien Germez
    Âge : 26
    Localisation : France, Haut Rhin (Alsace)

    Informations professionnelles :
    Activité : Ingénieur réalisateur
    Secteur : Industrie

    Informations forums :
    Inscription : mars 2011
    Messages : 3 158
    Points : 23 643
    Points
    23 643

    Par défaut

    Hello,

    Bizarre ce comportement.
    J'ai pas en mémoire de problème similaire avec Hibernate (J2EE).
    Donc j'aurais tendance à dire que c'est lié à ton framework
    Vous souhaitez participer à la rubrique Développement Web, contactez-moi !
    Avant toute chose : lire le mode d'emploi du forum et ses règles.
    Je ne réponds pas aux questions techniques en MP.

  4. #4
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    Merci pour ce retour.
    Citation Envoyé par FirePrawn
    Donc j'aurais tendance à dire que c'est lié à ton framework

    Je crains que ça soit une restriction de l'ORM de ce FW.

    Après moult recherches (pas si étonnant de ne pas trouver le moindre exemple de code pour ce cas), je tombe sur ces discussions :
    How can I use joint primary keys and Kohana 3 ORM?
    KohanaPHP » Kohana v3.x » ORM
    Qui dit (entre autre) :
    Kohana doesn't support compound primary keys
    (en traduction avec GG) :
    Si quelqu'un a cette mise en œuvre proprement assez, nous pouvons la considérer, mais personnellement, je ne vois pas un usage assez commun pour ce que je suis le déplacer pour réexamen 3.3.0.

    La façon la plus simple pour sélectionner une ligne de table qui a plusieurs clés primaires est d'ajouter une colonne id auto incrémentation de la table et utiliser à la place de la clé sur plusieurs colonnes.

    Nous n'allons pas à l'inclure dans ORM de sitôt. Dans l'avenir, nous pouvons créer une nouvelle question si nécessaire pour cela.

    Du coup, j'ai une autre question :
    - Est-il mieux de créer un ID auto incrémenté dans ces cas là pour exploiter l'ORM
    - Ou vaut il mieux ne pas le faire (respecter les base des conception de Bdd) et ne pas exploiter l'ORM dans ces cas là pour faire les requêtes directement (car c'est possible, l'ORM n'est une obligation partout).


    Pour le moment j'en suis au début d'un site Web, donc rien est irréversible.
    Au feeling comme ça, je dirais qu'il serait mieux de créer un ID auto incrémenté pour exploiter pleinement l'ORM, plus particulièrement pour la partie validation (formulaire ou autre) qui prévoit de placer les règles dans le Model (ce qui évitera de les (re)définir dans le Controler dans le cas contraire.


    Tout retour sur ce point sera le bien venu.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  5. #5
    Modérateur
    Avatar de rawsrc
    Homme Profil pro Martin
    Dev indep
    Inscrit en
    mars 2004
    Messages
    3 616
    Détails du profil
    Informations personnelles :
    Nom : Homme Martin
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : mars 2004
    Messages : 3 616
    Points : 8 938
    Points
    8 938

    Par défaut

    Bonjour,
    Citation Envoyé par RunCodePhp Voir le message
    Est-il mieux de créer un ID auto incrémenté dans ces cas là pour exploiter l'ORM
    - Ou vaut il mieux ne pas le faire (respecter les base des conception de Bdd) et ne pas exploiter l'ORM dans ces cas là pour faire les requêtes directement (car c'est possible, l'ORM n'est une obligation partout).
    Je vais t'éclairer un peu. Pour ce que je m'en souvienne, les moteurs de base de données gèrent automatiquement un id autonum pour absolument toutes les tables. Donc si tu ne l'affiches pas, il est quand même présent pour le bon fonctionnement de l'ensemble.
    J'ai toujours pour habitude de démarrer mes tables avec un id autonum et après je fais ma salade au niveau des index, index composés, des liens...
    D'expérience, j'ai aussi arrêté d'abuser des clés composées (sauf cas rarissimes). Il est plus simple de jouer avec une seule clé externe qu'avec un paquet.

    Pour ce qui est de l'usage d'un ORM en PHP, il faut faire attention au goulet d'étranglement dès la montée en charge.
    # Dans la Création, tout est permis mais tout n'est pas utile...

  6. #6
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    Citation Envoyé par rawsrc
    J'ai toujours pour habitude de démarrer mes tables avec un id autonum et après je fais ma salade au niveau des index, index composés, des liens...
    D'expérience, j'ai aussi arrêté d'abuser des clés composées (sauf cas rarissimes). Il est plus simple de jouer avec une seule clé externe qu'avec un paquet.
    Donc tu sous entendrais par là que cette restriction que je perçois serait un faut problème, voire à mieux concevoir les choses (plus simple, ...).

    C'est vrai que je me dis que ce ne serait pas si contraignant que ça, car rien m'empêche de créer cet ID auto incrémenté et de créer un INDEX UNIQUE pour les clés composées.
    Du coup plus de problème de doublons possible (ce qui est recherché en créant des clé primaires composées).
    Je pense que faire comme ceci devrait faire l'affaire.


    Pour ce qui est de l'usage d'un ORM en PHP, il faut faire attention au goulet d'étranglement dès la montée en charge.
    C'est la 1ère fois que je m'aventure à utiliser une ORM, et je remarque qu'on récupère beaucoup de données inutiles, sans compter que les Objets sont assez conséquents/volumineux aussi.
    Faudra faire attention c'est vrai.


    Plutôt rassurant ton intervention. Merci
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  7. #7
    Modérateur
    Avatar de rawsrc
    Homme Profil pro Martin
    Dev indep
    Inscrit en
    mars 2004
    Messages
    3 616
    Détails du profil
    Informations personnelles :
    Nom : Homme Martin
    Âge : 38
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : mars 2004
    Messages : 3 616
    Points : 8 938
    Points
    8 938

    Par défaut

    Citation Envoyé par RunCodePhp Voir le message
    C'est la 1ère fois que je m'aventure à utiliser une ORM, et je remarque qu'on récupère beaucoup de données inutiles, sans compter que les Objets sont assez conséquents/volumineux aussi.
    Faudra faire attention c'est vrai
    Alors bonne chance, si tu as mangé du SQL en pagaille pendant des années, tu vas voir que c'est pas si simple de s'en affranchir...
    Ensuite il y a la réalité. Sur le papier l'ORM c'est très probablement la panacée mais en pratique c'est tout à fait autre chose.
    Pour m'être penché sur Doctrine, je suis arrivé à la conclusion : tout ça pour s'affranchir du SQL. Et ben !?!!? Autant le garder alors...

    Personnellement je n'ai pas été ébloui. En tout cas, cela m'a motivé pour créer une couche d'abstraction de base de données qui vient en complément du SQL et non à sa place.
    Après, pour tous les gros projets PHP que j'ai vu, l'ORM était tout simplement banni. Et j'ai des collègues qui ont participé à plusieurs projets de retrait de Doctrine.
    Cela est surtout vrai quand les pages ne sont pas facilement cachables à cause du volume du contenu dynamique à chaque rafraîchissement, l'ORM devient vite un sacré goulet d'étranglement, crois-moi.
    # Dans la Création, tout est permis mais tout n'est pas utile...

  8. #8
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    D'abord, merci pour les infos

    Il est clair que je débute dans ce domaine (l'ORM), donc je découvre, mais l'envie est de savoir comment tout ça fonctionne est plus grande que la raison.

    Tu dois surement avoir raison, rien qu'à éplucher un peu le code de l'ORM on voit que ça charge à bloc.

    Donc si les perfs dégringoles à cause de ça, et bien tant pis, j'aurais au moins cette expérience là.
    Le projet est particulièrement modeste (aucun enjeu financier), donc utiliser un ORM est largement sur-dimensionné, utiliser un framework l'est déjà.
    Puis j'ai pas le niveau pour faire des projets de ouf.

    Si vraiment ça cause problème, Kohana n'oblige en rien d'utiliser l'ORM, donc il y a moyen de revenir/corriger pour quelque chose de plus classique.


    En tout cas j'en prend bien note.
    Merci encore.
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  9. #9
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    Encore une discussion qui me conforte dans l'avis qu'un ORM est vraiment un Objet Réellement Merdique !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  10. #10
    Expert Confirmé Avatar de RunCodePhp
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 963
    Détails du profil
    Informations personnelles :
    Localisation : Réunion

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 963
    Points : 3 910
    Points
    3 910

    Par défaut

    Citation Envoyé par CinePhil
    Encore une discussion qui me conforte dans l'avis qu'un ORM est vraiment un Objet Réellement Merdique !
    Pas mal

    J'en profite du coup pour faire un p'tit retour à ce sujet.

    D'abord, j'aimerais bien savoir quel est le (ou les) vrai objectif visé d'un ORM, car finalement j'ai énormément de mal à voir ou il est.


    A cet instant je considère un ORM comme une brique, et ici cette brique devrait logiquement remplir au moins 1 objectif :
    -> Simplifier l'accès aux données (de son usage et de l'ensemble du code effectué)

    Or, pour aboutir à cette (soit disant) simplification il faut faire tout pleins de codes au préalable que je considère complexes avant d'y parvenir.

    De plus, une parfaite maitrise de son ORM (pas sûr que tous les ORM adoptent les mêmes concepts) pour en tirer pleinement parti, cela suppose de faire un apprentissage plus ou moins poussé.

    Aussi, pour peu que son projet soit spécifique, on est pas garanti que l'ORM soit adapté ou suffisamment abouti pour répondre à tous les cas (du moins je le ressent ainsi).

    Mais encore, il y a apparemment obligation que le projet soit "pensé" (plutôt spécifié pour être plus précis, donc avant d'écrire la moindre ligne de code) pour l'usage de l'ORM.
    En somme que le projet soit structuré pour exploiter l'ORM.
    (Une question qu'il me viens, c'est si on à intègre une autre brique/librairie/ou autre ... qui demande aussi une structure particulière pas tout à fait en phase avec un ORM, on fait comment ???)



    Tout ça pour dire que du jour au lendemain j'ai jeté l'éponge.
    Pour l'ORM on verra ça peut être un autre jour.

    -> Pour ma part on abouti à un code assez conséquent mais surtout complexe, donc non maintenable (ou difficilement).
    -> Grosse perte de temps pour peu que des remaniements soient fait en cours de route coté Bdd (ce qui me semble être le cas à tout projet).


    Bref ...
    Ils sont où les avantages d'un ORM ? (A part faire une prouesse technique ?)
    Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20
    Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra]

  11. #11
    Modérateur
    Avatar de grunk
    Homme Profil pro Olivier
    Dév. Web / Android
    Inscrit en
    août 2003
    Messages
    3 110
    Détails du profil
    Informations personnelles :
    Nom : Homme Olivier
    Âge : 30
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Dév. Web / Android
    Secteur : Industrie

    Informations forums :
    Inscription : août 2003
    Messages : 3 110
    Points : 7 462
    Points
    7 462

    Par défaut

    Pas mieux, je me suis essayé un peu a Doctrine2 via SF2 et j'avoue être assez réservé.
    C'est extrêmement pratique quand on est dans le cas d'école , l'entité simple toute seul dans son coin.
    Faut reconnaître que faire une classe mettre 3 annotations et voir la table se créer toute seule c'est sympa.

    Mais des qu'on tombe sur des cas plus complexe , ça devient vite problématique et il faut une très bonne connaissance de l'outil pour ne pas exploser le serveur , là ou une simple requête aurait suffit.

    Il y'a des outil tel que idorm qui me semble pas mal. Un mix assez subtile des avantages des ORM sans trop de contraintes
    Pry Framework php5

  12. #12
    Membre actif
    Homme Profil pro Aurélien LEQUOY
    Directeur technique
    Inscrit en
    février 2011
    Messages
    139
    Détails du profil
    Informations personnelles :
    Nom : Homme Aurélien LEQUOY
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : Transports

    Informations forums :
    Inscription : février 2011
    Messages : 139
    Points : 152
    Points
    152

    Par défaut

    Citation Envoyé par rawsrc Voir le message
    Alors bonne chance, si tu as mangé du SQL en pagaille pendant des années, tu vas voir que c'est pas si simple de s'en affranchir...
    Ensuite il y a la réalité. Sur le papier l'ORM c'est très probablement la panacée mais en pratique c'est tout à fait autre chose.
    Pour m'être penché sur Doctrine, je suis arrivé à la conclusion : tout ça pour s'affranchir du SQL. Et ben !?!!? Autant le garder alors...

    Personnellement je n'ai pas été ébloui. En tout cas, cela m'a motivé pour créer une couche d'abstraction de base de données qui vient en complément du SQL et non à sa place.
    Après, pour tous les gros projets PHP que j'ai vu, l'ORM était tout simplement banni. Et j'ai des collègues qui ont participé à plusieurs projets de retrait de Doctrine.
    Cela est surtout vrai quand les pages ne sont pas facilement cachables à cause du volume du contenu dynamique à chaque rafraîchissement, l'ORM devient vite un sacré goulet d'étranglement, crois-moi.

    Oui, je constate la même chose tous ceux qui ont utilisé Doctrine cherche un moyen maintenant de s'en affranchir. Et c'est complètement incompatible avec des traitements de données des qu'on monte un peu en volumétrie.


    Pour ma part je rajoute une mini couche qui va tester :

    - l'ensemble des élément avant l'insertion en base (insert / update / clef étrangère)

    - l'historisation des données pour les tables qui sont flagé comme tel (qui à ajouter / modifié / effacé quoi)

    - vérification avant les delete (et historisation si flag = 1)

    Pour les select je ne change rien du tout.


    Et a la fin de chaque page j'afficher l'ensemble des requêtes avec le temps d’exécution, le nombre de ligne retourné, (et leur localisation fichier & ligne) pour chacune d'entre elles.

    Permet de gagner un temps précieux, pour détecter du code pourri, ou de voir si un développeur boucle 100 fois sur une même requête.

  13. #13
    ovh
    ovh est déconnecté
    Rédacteur
    Avatar de ovh
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mai 2002
    Messages
    3 761
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : mai 2002
    Messages : 3 761
    Points : 5 896
    Points
    5 896

    Par défaut

    Les ORM bien faits comme Doctrine 2 (PHP), Hibernate (Java), ou SQL Alchemy (Python) ont pour intérêt de pouvoir créer une application vraiment orientée objet. Or, la plupart des projets PHP n'ont pas une bonne pratique de l'OO, et pour moi le problème principal vient de là.

    Beaucoup de projets utilisent l'objet parce qu'ils sont basés sur un framework, mais n'ont pas de réelle couche métier méritant le qualificatif d'OO. Un ensemble de classes qui représentent les tables de la base de données (comme on fait classiquement avec un ORM), c'est-à-dire des classes d'entités, ne suffit pas pour constituer une couche métier ! Une vraie couche métier, c'est avant tout une architecture conçue en pur objet avec des classes qui sont liées entre elles par des associations, de l'héritage, qui s'échangent des messages, etc. L'aspect persistance est totalement découplé et géré à part par un service "ORM".
    Et seuls les ORM de type "data mapper" tels que ceux que j'ai cité permettent ce type d'architecture.
    Les ORM classiques de type "active record", (où les classes d'entité héritent de classes de base offrant des méthodes de persistance) conduisent bien souvent à des projets faussement OO, où la logique métier est située dans les contrôleurs qui utilisent directement les classes d'entité...

    Quant à l'aspect performance, l'ORM n'est pas magique. Ce n'est pas parce qu'on utilise un ORM qu'il ne faut plus faire ses propres requêtes. Pour une fonctionalité nécessitant de travailler avec plusieurs tables, le plus efficace est d'effectuer des jointures ciblées ramenant toutes les données nécessaires (comme on faisait à l'ancienne), plutôt que de ramener une entité principale et de récupérer toutes les associations une à une par des appels successifs à des méthodes "get", surtout dans des boucles ! C'est à cause de ce genre de pratiques qu'on arrive à des perfs en-dessous de tout. Ce n'est pas lié à l'ORM, mais à la façon dont on l'utilise.
    Et dans certains cas, il est nécessaire de débrancher l'ORM et d'utiliser la couche d'accès directe aux données (PDO ou la couche équivalente dans votre ORM) pour être plus efficace (utilisation de procédures stockées, de vues, de requêtes SQL complexes en langage natif, etc.), ce n'est pas anormal, ce n'est pas pour rien que les ORM permettent de le faire. Doctrine permet d'ailleurs de mapper le résultat d'une requête SQL native en graphe d'objets entité.

    Bref, l'ORM c'est bien, mais à condition d'en choisir un bon et de bien l'utiliser.
    Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...

    Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.
    Je n'ai rien à voir avec la société www.ovh.com !

  14. #14
    Membre éprouvé
    Homme Profil pro Thomas Dutrion
    Développeur Web
    Inscrit en
    février 2009
    Messages
    275
    Détails du profil
    Informations personnelles :
    Nom : Homme Thomas Dutrion
    Âge : 26
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 275
    Points : 438
    Points
    438

    Par défaut

    Concernant les performances, Doctrine2 fournit le DQL (sorte de SQL completement objet), et fournit aussi de quoi cacher les requetes (http://docs.doctrine-project.org/en/...he-recommended) et les metadata...

    Pour le cas du cache de requetes, il s'agit de pourvoir utiliser le query builder pour s'affranchir des jointures sql en se basant sur les relations entre les objets, donc le query builder va fabriquer la requete, puis la cacher jusqu'au prochain changement pour ne pas avoir a reparcourir les objets servant a creer la requete.

    Au final, avec un data mapper comme doctrine2 on va retrouver du sql assez optimise si on sait s'en servir, la consommation supplementaire residant dans l'hydratation des objets...

  15. #15
    Modérateur
    Avatar de CinePhil
    Homme Profil pro Philippe Leménager
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    13 820
    Détails du profil
    Informations personnelles :
    Nom : Homme Philippe Leménager
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 13 820
    Points : 24 812
    Points
    24 812

    Par défaut

    Je n'ai pas essayé Doctrine mais j'ai été confronté malgré moi à Hibernate et j'avais constaté (dans les logs) que les requêtes n'étaient pas du tout optimisées pour le besoin... sauf à les écrire en SQL pur et à simplement les soumettre via Hibernate, ce qui rend l'ORM fort peu utile.

    La bonne approche serait ce que SQLPro appelle le développement en "base de données épaisse" :
    - les objets métier dans la partie applicative ;
    - un modèle de données solide en BDD ;
    - une interrogation de la BDD via des vues SQL qui reproduisent la couche métier (que j'appelle le "modèle logique de données") ;
    - une mise à jour des données via des procédures SQL appelées par le programme applicatif car il est souvent impossible de mettre à jour les données directement via les vues ;
    - la récupération et le traitement, dans l'application, des éventuelles erreurs renvoyées par le SGBD.

    Voir un article de SQLPro ici.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •