Zend FR

Hum... après avoir utilisé Propel sur un projet assez gros, je suis un peu sceptique sur l'intérêt des ORM "étendus". Je vois bien l'intérêt d'utiliser des entités pour représenter des lignes de tables avec des fonctions CRUD basiques. Par contre suivre les relations en PHP au lieu de les suivre en SQL... Je me pose la même question que toi : est-ce bien raisonnable... Finalement je trouve que ça va plus vite en SQL.

Bref, dans mes projets, j'utilise souvent un "mini ORM maison" qui assure les fonctions suivantes :
- CRUD simple
- Gestion basique du polymorphisme pour gérer l'héritage d'objets PHP au sens "class Toto extends Titi" (quand la famille d'objets arrive dans la même table)
- Gestion d'une sorte de hiérarchie d'objets au sens node, parent node, children
- Gestion de conversions de types (un Zend_Date est transformé comme il faut pour arriver dans un DATE_TIME par exemple)
- Gestion du multilangues (oui, c'est spécifique, mais c'est tellement courant que je l'ai mis dans l'ORM....)

et quand j'ai des relations à suivre, je fais du bête SQL que j'injecte ensuite pour recréer mes entités (populate).

A+, Philippe

PS : je suis ouvert à toute discussion, mais pitié pas de troll sur ce sujet... Que des arguments justifiés et modérés...

Bonjour

l'un n'empêche pas l'autre
on peut très bien utiliser un ORM pour ce qu'il sait faire et bien faire et aussi dans certain cas faire faire des jointures au moteur SQL

faire un jointure n'est pas toujours la bonne solution
prenons un exemple
j'ai une table principale avec 5 champs texte varchar(30) et une table fille avec 10 champs varchar(50)
j'ai en moyenne 500 éléments fils par maitre. et j'ai 1000 maitre
utiliser une jointure va me faire 1 seule requêtes qui vas remonter un volume moyen de donnée de 500 x 30 x 5 + 500 x 50 x 10 par élément maitre les champs maitres étant répliqué à chaque ligne remonté soit donc 1000 x 500 x ( 30 x 5 + 50 x 10 ) = 325 000 000
à contrario sans jointure je vais avoir 1 requête sur la table maitre et autant de requête sur la table fille que d'élément dans la table maitre soit donc 1001 requêtes la première va remonter 5 x 30 x 1000 et les 1000 autres 500 x 50 x 10 soit donc (5 x 30 x 1000) + (1000 x 500 x 50 x 10) = 250 150 000
on vois vite que la surcharge de donnée de la première solution par rapport à la seconde est de 1,2 environ mais que le nombre de requête est d'un rapport de 1 à 1000. le coût global sur le moteur est très largement en faveur de la première solution.

maintenant prenons une table principale de 5 champs 2 varchar(30) et 3 blob de 5 Mo (en moyenne) chacun et une table fille identique à la précédente soit 10 champs varchar(50)
cette fois en moyenne 5 éléments fils par maitre. et j'ai 1000 maitre

la solution de la jointure donne toujours une seule requête avec un poids de
1000 x 5 x ( 1024 x 1024 x 5 x 3 + 30 x 2 + 50 x 10 ) = 78 646 000 000
la solution sans jointure donne
(1024 x 1024 x 5 x 3 + 30 x 2) x 1000 + (1000 x 5 x 50 x 10) = 15 731 200 000 le sur coût est de 4.9 pour la jointure et le rapport des requête est  de 1 à 5 en nombre de requêtes

pour 50 fils on à un sur coût en requêtes de 1 à 50 et en poids qui augmente proportionnellement soit 49

ces exemples sont des cas caricaturaux et dans la vrais vie on fait attention de ne remonter que les colonnes nécessaires. mais sur de grosse base il faut faire attention à ce genre de rapport pour la cas précédent avec 5 fils
en imaginant qu'on ait réellement besoin de ses infos le volume de donnée opérationnel est celui donné sans jointure soit environs 18 Mo faire 6 requêtes pour y arriver à un coût mais devoir remonter 78 Go de donnée pour ne faire qu'une seule requête n'est pas l'idéal.

il n'y a donc pas de règles absolue et il convient d'être pragmatique et de bien cibler la nature des données qu'on manipule.
et les organiser d'une façon différente permet de s'affranchir de certain problèmes.

si on reprends l'exemple avec 5 fils
mais on décide de faire une jointure mais en ne remontant que les champs varchar(30) de la table principale et une 2eme requête pour remonter les blob
on obtient
1000 x 5 x ( 30 x 2 + 50 x 10 ) = 2 800 000 pour la jointure
1000 x ( 1024 x 1024 x 5 x 3 ) = 15 728 640 000 pour les blob

soit un total de         15 731 440 000 pour 2 requêtes
cela est à comparer avec 15 731 200 000 pour 6 requêtes
et                       78 646 000 000 pour 1 requête

avec 50 fils
1000 x 50 x ( 30 x 2 + 50 x 10 ) = 28 000 000 pour la jointure
1000 x ( 1024 x 1024 x 5 x 3 ) = 15 728 640 000 pour les blob

soit un total de          15 756 640 000 pour  2 requêtes
cela est à comparer avec  15 753 700 000 pour 51 requêtes
et                       786 460 000 000 pour  1 requête

un seul mot d'ordre adaptez votre stratégie à votre dommaine fonctionnel
A+JYT

Il me semblait avoir lu que ZF intégrait pourtant la gestion des namespaces PHP et ce depuis longtemps. Ou alors je me trompes....

Hello,

Tiens un qui n'a pas suivi mon webinar sur ZF 1.10 : autrement il saurait que ZF 1.10 intègre une modification de Zend_Loader::loadClass() pour gérer les namespaces suivant la PSR-0 (http://groups.google.com/group/php-stan … l-proposal)

@+

mikaelkael a écrit:

Hello,

Tiens un qui n'a pas suivi mon webinar sur ZF 1.10 : autrement il saurait que ZF 1.10 intègre une modification de Zend_Loader::loadClass() pour gérer les namespaces suivant la PSR-0 (http://groups.google.com/group/php-stan … l-proposal)

@+

Merde, je me suis fait cramer en beauté

Va falloir que j'aille voir tout ca de plus près alors... Car DC2 m'intéresse grandement.

On trouve aussi adaptateur Zend_Auth pour doctrine
http://framework.zend.com/wiki/pages/vi … Id=3866950