Généralités sur les ORM

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

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.

[rawsrc]

Bonjour,

Envoyé par RunCodePhp

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]

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

[rawsrc]

Envoyé par RunCodePhp

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]

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

[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