Discussion :

[RunCodePhp]

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

[RunCodePhp]

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 ?

[FirePrawn]

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

[RunCodePhp]

Merci pour ce retour.

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.

[rawsrc]

Bonjour,

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.

[RunCodePhp]

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

[rawsrc]

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.

[RunCodePhp]

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.

[CinePhil]

Encore une discussion qui me conforte dans l'avis qu'un ORM est vraiment un Objet Réellement Merdique !

[RunCodePhp]

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 ?)

[grunk]

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

[Aurélien LEQUOY]

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.

[ovh]

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.

[tdutrion]

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...

[CinePhil]

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.