Discussion :

[avairet]

Si cette couche a pour but non plus d'adapter l'un à l'autre, mais de forcer l'une a rentrer dans l'autre, l'objectif est manqué.

Donc dans notre cas, on est plutôt dans la seconde hypothèse : forçage ?!

[Antoun]

Pour commencer, disons qu'on peut poser les questions à deux niveaux différents, avec (pour ma part) des réponses opposées :

Au niveau théorique : les gars de Cake ont développé une solution partielle, ce qui est assez normal ; ce qu'il l'est moins, c'est qu'ils devraient bosser à étendre leur solution plutôt que de dire comment doit être la couche de persistance Pour être tout à fait franc, c'est assez inquiétant que des mecs qui développent une couche de mapping relationnel/objet aient une attitude aussi bornée vis-à-
vis du modèle relationnel.

Au niveau pratique : la question est effectivement "faut-il refuser d'utiliser Cake pour cette raison ?". Je pense qu'il faut répondre de manière assez pragmatique. Y a-t-il des alternatives ? Le développement est-il déjà avancé avec Cake ? Les pertes de performances sont-elles vraiment handicapantes, ou simplement significatives ? Mon petit doigt me dit qu'il est assez probable que tu en arrives à "Cake a tort, mais je vais l'utiliser quand même !".

[avairet]

Bonjour Antoun,

Merci de t'être mêlé à cette conversation et de donner un point de vue très pertinent !

Pour modérer un peu tes propos, comme je ne suis pas encore un expert de Cake et que j'ai parfois du mal avec l'anglo-américain très pointu ou très familier, je ne peux pas affirmer que la core team de Cake soit totalement bornée sur ces sujets qui nous occupent... c'est juste un sentiment partagé par quelques-uns à la suite des discussions engagées ci et là !

En fait Cake se veut le portage "à l'identique" de Ruby sur PHP, ses créateurs ont donc implémenté le pattern "Active records" pour faire du mapping. Je ne connais pas Ruby, donc je ne sais pas si ses développeurs se sont assis sur le modèle relationnel eux-aussi, ce qui expliquerait le choix dans Cake.

Sinon, effectivement ton petit doigt a raison... malheureusement !

Je suis contraint par ma hiérarchie et c'est vrai qu'une fois goûté au gâteau, on a du mal à faire autrement ! Mais j'aimerais influer sur la communauté pour qu'à l'avenir cette problématique soit prise en compte. Car dans l'optique d'une certification ISO du framework par exemple, et bien cette liberté prise avec le modèle relationnel les conduirait tout droit dans le mur.
Maintenant, j'ai de très solides arguments grâce à vous tous, mais je vais avoir des difficultés à formuler tout cela en bon anglais et surtout à répondre aux critiques qu'on me fera nécessairement...

Question perfs, il faudrait faire des benchmarks, ce dont je me sens bien incapable pour le moment... nous verrons donc "à l'usage", si le portail que nous développons rame ou pas !

Encore merci de ton éclairage.

Avairet

[TheLeadingEdge]

Tu sembles connaître Cake, donc tu refuserais de l'utiliser pour cette raison ?

Absolument pas. Je suis désolé si j'ai pu donner cette impression. Je donne juste mon idée sur ce que doit être un O/RM. J'ai juste fait un peu de provoc (mea culpa) en réaction à l'attitude ''psycho-rigide'' de tes interlocuteurs.

L'utiliser ou pas Antoun a déjà plus ou moins répondu à la question. Est-ce que les avantages qu'il apporte l'emportent sur les désagréments qu'il cause ?
En gros mon interrogation serait :
Je développe vite et facilement la partie métier (et probablement IHM) de mon appli. Mais en contrepartie on m'impose certaines contraintes lorsque je vais concevoir ma couche données. Est-ce que ces contraintes vont dégrader les perf. de mon appli. lorsqu'elle sera passée en prod. ou feront courir des riques à l'intégrité de mes données ?
Si tu maitrises suffisement les concepts de la modélisation relationnelle, tu peux utiliser des surrogates keys en complément (et surtout pas à la place) des clefs naturelles. [TROLL]ce vieux dinosaure de modèle relationnel est finalement bien souple et bien arrangeant tt de même. Non ? [/TROLL]
Quand à l''impact sur les perfs, la je ne peux rien en dire je ne suis pas DBA. Mais FSMREL t'a déjà donné des élements de réponse pour faire ton choix.

[avairet]

Salut TheLeading !

Merci de ton avis complémentaire.

Je développe vite et facilement la partie métier (et probablement IHM) de mon appli

Réponse : OUI, les frameworks orientés Web sont là pour ça.

Mais en contrepartie on m'impose certaines contraintes lorsque je vais concevoir ma couche données

Ben oui, mais habituellement, on conçoit d'abord la couche de données avant de générer le code, non ? Et c'est là que cela pose problème, car moi je génère un modèle de données conforme, soit à la mano, soit avec DbDesigner ou PhpMyAdmin par exemple. Et la chose de base exécutée par Cake, c'est se connecter à ma base et faire des DESCRIBE sur chaque table pour en connaître la structure. Comme d'autres frameworks, il s'appuie sur des conventions de nommage pour les tables et les champs. Donc quand il découvre ma structure, il panique car il voit des Primary Keys sur 2 colonnes et des tables d'association réflexive sans colonne Id auto-increment.

Est-ce que ces contraintes vont dégrader les perf. de mon appli. lorsqu'elle sera passée en prod. ou feront courir des riques à l'intégrité de mes données ?

Pour la sécurité, on ne peut répondre que oui, puisque les contraintes SQL de base ne seront pas respectées, notamment la PK sur 2 colonnes pour ma table d'association réflexive... Il est donc potentiellement possible d'enregistrer 2 fois le même couple de tuples.

Pour les perfs, je pense que cela n'est pas vraiment significatif dans le type de projet que je développe et Cake dispose de nombreux systèmes de cache qui doivent permettre d'améliorer les choses.

Si tu maitrises suffisement les concepts de la modélisation relationnelle, tu peux utiliser des surrogates keys en complément (et surtout pas à la place) des clefs naturelles.

Je reste modeste et je préfère dire "je connais" les concepts de modélisation plutôt que "je maîtrise". Donc ton idée de surrogates keys et de clef naturelle n'est pas parlante pour moi, mais je vais réviser !


C'est vraiment cool d'avoir des gens passionnés et polis qui prennent le temps de répondre ! Merci à tous !

[Antoun]

Salut TheLeading !
Pour la sécurité, on ne peut répondre que oui, puisque les contraintes SQL de base ne seront pas respectées, notamment la PK sur 2 colonnes pour ma table d'association réflexive... Il est donc potentiellement possible d'enregistrer 2 fois le même couple de tuples.

Il suffit que tu mettes une contrainte UNIQUE sur le couple pour éviter cela.

[avairet]

Ben oui, mais j'ai déjà ma PK sur le couple, comment veux-tu que j'ajoute un index UNIQUE ?
En suivant les échanges ici et ailleurs, j'avais donc créé ma table de cette manière pour qu'elle reste conforme au niveau du modèle et qu'elle "marche" aussi avec Cake :

CREATE TABLE `complements` (
`complete_id` int(10) unsigned NOT NULL,
`completant_id` int(10) unsigned NOT NULL,
`id` int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (`complete_id`,`completant_id`),
UNIQUE KEY `id` (`id`),
) ENGINE=MyISAM;

Ce que tu me dis c'est de "détruire" le modèle relationnel pour avoir :

CREATE TABLE `complements` (
`complete_id` int(10) unsigned NOT NULL,
`completant_id` int(10) unsigned NOT NULL,
`id` int(10) unsigned NOT NULL auto_increment,
PRIMARY KEY (`id`),
UNIQUE KEY `couple` (`complete_id`, `completant_id`),
) ENGINE=MyISAM;

Est-ce bien raisonnable

[koala01]

Salut,

Personnellement, je ferais valoir que les PK composées sont, tout simplement, parfois une nécessité de terrain, et qu'il est beaucoup plus utile d'avoir un framework qui puisse s'adapter aux différents shémas rencontrés (de manière à laisser le choix le plus longtemps possible)qu'un framework qui implique d'avoir été choisi alors que l'on n'a même pas encore terminé l'analyse complete

En Belgique, par exemple, cela se remarque fort avec les codes postaux depuis la fusion des communes qui a eu lieu... il y a longtemps:

Ainsi, en Belgique, on trouve le code postal 1330 pour Rixensart, Rosieres et Genval, et le code postal 1380 pour pas moins de... 5 (anciennes) communes.

Et, quand on demande aux gens leur adresse, ils nous répondent de préférence Rosières, Ohain ou Genval...

A l'inverse, on ne trouve pas moins de 20 codes postaux pour la seule entité de Bruxelles, et, bien que 1200 corresponde à Wolluwe Saint Lambert (ou Saint Pierre, je ne sais plus), l'adresse officielle n'est autre que ... 1200 Bruxelles.

Il me semble d'ailleurs que c'est aussi le cas d'autres grandes villes comme Anvers, Liège ou Charleroi

Typiquement, le code postal et le nom de la commune sont deux clés candidates idéales, car c'est réellement sur (l'une de) ces deux informations qu'une recherche va porter.

Si l'on vient à rajouter un champs id, les recherches (de noms de rue, ou de localisation sur plan par exemples) vont devenir pour le moins abracadabrandesques à mettre en oeuvre.

Maintenant, qui ira, chez les anglophone, s'apesentir sur les déboires d'un pays qui ne compte "que" 10.000.000 d'habitants

[Antoun]

Ben oui, mais j'ai déjà ma PK sur le couple, comment veux-tu que j'ajoute un index UNIQUE ?
(...)
Ce que tu me dis c'est de "détruire" le modèle relationnel pour avoir :

Non, je ne veux rien détruire du tout.

Si tu as ta PK sur le couple, il ne peut pas y avoir de doublons du couple, donc c'est OK.
Si tu déplaces ta PK sur une colonne en auto-incrément pour te conformer à Cake, ainsi que tu en évoquais la possibilité, il faut alors tu ajoutes un UNIQUE sur le couple ; tu gardes ainsi le même niveau d'intégrité des données.

[Antoun]

Salut,

Personnellement, je ferais valoir que les PK composées sont, tout simplement, parfois une nécessité de terrain, et qu'il est beaucoup plus utile d'avoir un framework qui puisse s'adapter aux différents shémas rencontrés (de manière à laisser le choix le plus longtemps possible) qu'un framework qui implique d'avoir été choisi alors que l'on n'a même pas encore terminé l'analyse complete

Je crois qu'on est tous d'accord là-dessus, mais ça ne fait pas trop avancer le schmilblick.

[avairet]

Bonjour à tous,

J'ai enfin relancé la discussion de fond sur les PK dans CakePHP:
http://groups.google.com/group/cake-...6e1dd6f853b37f

Le moins que l'on puisse dire c'est que cela en énerve plus d'un...
Et les réponses tournent toujours autour de : "fais le toi-même" ou "si tu as besoin de PK composée, n'utilise pas Cake !"

Bref, parce que c'est compliqué à implémenter ou inutile pour la plupart des développeurs, ils bottent en touche et renvoie cela aux calendes grecques !

J'aimerai à nouveau avoir vos réactions à celà...

Avairet

[Antoun]

pas surpris ! Les éditeurs réagissent toujours comme ça.

[fsmrel]

Je relève quelques points dans la discussion que vous avez relancée. Il n'y a rien à espérer de la part de ces gens...

> Only one thing: a Primary Key is not equal to Unique not null index!

That's exactly what I've been saying from the beginning. The difference is, one is an application key which has meaning within the context of the application itself, and one is a business key which satisfies some business requirement.

Manifestement l’auteur (nate) de ce dernier paragraphe raisonne du seul point de vue du programmeur et considère paradoxalement un concept relevant de la tuyauterie (du niveau physique), l’index, comme relevant de l’applicatif en violation des principes d’indépendance des données et des traitements, du physique et du logique... La modélisation des données est sans doute quelque chose qui ne doit l’intéresser que très modérément.

The fact is, compound primary keys are really just not requested that often.

Une fois de plus, ignoratio elenchi. Les associations de type M:N (sources de clés multi-attributs) ne sont donc pas monnaie courante ? Dans le même sens, les lignes de facture, les chambres dans les hôtels, les adresses des personnes, l’historique des salaires des employés, les mouvements attachés aux comptes bancaires, etc., toutes ces choses à l'origine de clés multi-attributs, se rencontreraient donc si peu souvent ? Et qui, si l'on descend dans la soute, ne poseraient aucun problème de performance lors des traitements ? (au moins dans le cas des grandes bases de données pour lesquelles les temps de réponse sont critiques, et dans l'état actuel de la technologie). La réalisation de prototypes pour analyser les performances des bases de données et mettre en évidence le phénomène d’I/O bound ne doit pas concerner ceux qui font dans le Cake (parce qu’ils n’ont manifestement pas idée de ce dont il s’agit).

Even if they were, we've decided it's just not something we're going to implement, because it adds too much overhead in terms of complexity.

Ceci est la raison la plus plausible. En effet, retrouver la structure de la clé primaire d’une table (ou toute autre clé candidate) et celle d’une clé étrangère, suppose en toute logique de consulter les tables du catalogue relationnel, dont l’organisation (mais non l'esprit) change d’un SGBDR à l’autre ; toutefois ces derniers ne sont quand même pas si nombreux et leur catalogue est en principe stabilisé. Transformer son laxisme en fonctionnalité, voilà un guide de réflexion intéressant...

we make decisions on what to support and what not to support based on the driving philosophies of this project

Un projet à plus d’une "philosophie", ça laisse songeur. En tout cas, l’argument de la "complexité" de la consultation du catalogue relationnel est peut-être à la base d'une des philosophies de l’auteur de cette réflexion.


Pour en finir, comme le dit très justement TheLeadingEdge, on passe du monde relationnel (Relationland) au monde des objets (Objectland) et donc les concepts de clé primaire, clé candidate, clé étrangère n'ont pas lieu d'être, au bénéfice du seul OID, donnant lieu au niveau tabulaire à une clé primaire mono-attribut (une concession en quelque sorte). C'est donc parti pour le "pointer chasing". Pour le reste, circulons, il n'y a rien à voir.

[TheLeadingEdge]

J'ai l'impression que c'est un dialogue de sourds.
Je ne connais (tjours pas) Cake. Mais ils ne sera certainement jamais en short-list chez moi.

Bref, parce que c'est compliqué à implémenter ou inutile pour la plupart des développeurs, ils bottent en touche

Malheureusement, comme construire un modèle de données qui tient la route demande des compétences et du travail/temps, ce genre d'argument doit recevoir un écho tres favorable.
Genre ''Quand on veut noyer son chien, on dit qu'il a la rage''.
En gros ils ne sont pas capables d'assurer eux-même la persistance. Donc ils utilisent un SGBDr. Mais en même temps ils ne savent pas non plus dév. proprement la couche de mapping. Alors comme ils ne peuvent quand même pas demander à Mysql ou Oracle de développer pour prendre en compte les faiblesses de Cake, ils s'en sortent en affirmant gratuitement que le relationnel c'est has-been. Faut oser quand même. Si le relationnel c'est aussi mauvais ils font leur propre moteur objet qui sera certainement 1 merveille.

Et les réponses tournent toujours autour de : "fais le toi-même"

Ils te proposent de le faire toi-même. A la limite si tu en as la possibilité, pourquoi pas ?
Effectivement ce n'est pas à la couche métier (PHP) de gérer la persistance. Je conçois que se soit compliqué à faire de façon automatique et que ce ne soit pas leur ''tasse de thé'' de se prendre la tête avec des concepts qu'ils ignorent. Est-ce que Cake permet de faire le binding de façon manuelle ?

ou "si tu as besoin de PK composée, n'utilise pas Cake !"

Puisqu'ils te le proposent ;-)
Hibernate (qui pourtant m'a longtemps pris la tête pour la même raison) n'a pas du tout le même discours. Il faut dire que la persistance des données c'est leur business et qu'il ne considèrent pas ça comme une maladie honteuse (Histoire de compétence de personnes peut-être ?)
En qques mn tu crée une couche OR/M. Qui est le cas échéant capable de gérer automatiquement des clefs composites. Tu peux également faire toi même ton mapping. On arrive même à ''gommer'' dans le DC de la couche métier certaines erreurs de conception de la base ...Malheureusement je ne sais pas s'il génère du PHP.

Bon c'était mon 1/4 d'heure de mauvaise foi ;-)
C'est vrai que ça ne fait pas non plus avancer tes affaires.
La seule solution que je vois pour toi, c'est que tu modélises ta base de façon relationnelle (avec les identifiants naturels -qui leur donnent de l'urticaire- pour sécuriser tes données) et que lorsque tu auras validé ton schéma tu y ajoutes des surrogates keys comme PK partout où c'est nécessaire pour que Cake soit content

[avairet]

Un grand merci à tous les deux pour vos réponses et commentaires !
C'est rare d'avoir des "experts" qui répondent sur les forums avec pertinence et patience, même après plusieurs jours d'absence !

Quelques réponses :

@Fsmrel :

Une fois de plus, ignoratio elenchi. Les associations de type M:N (sources de clés multi-attributs) ne sont donc pas monnaie courante ?

Ben oui j'ai halluciné quand il a dit que cela n'était que raremement utile ! Il faut que je trouve le temps de formuler tes arguments en bon English, afin de leur faire admettre qu'ils ont tort. Toutefois, comme ils le disent en fin de discussion, ils ont déjà essayé et ont laissé tomber au profit de nombreuses autres choses très utiles.

La réalisation de prototypes pour analyser les performances des bases de données et mettre en évidence le phénomène d’I/O bound ne doit pas concerner ceux qui font dans le Cake (parce qu’ils n’ont manifestement pas idée de ce dont il s’agit).

Oui, je suppose... mais ils se défendent souvent par le "cache" qui est très finement customisable dans Cake. Et aussi par des benchmarks indépendants qui classent Cake largement en avance sur les deux autres frameworks PHP de référence internationale (Symfony et Zend Framework).

Un projet à plus d’une "philosophie", ça laisse songeur. En tout cas, l’argument de la "complexité" de la consultation du catalogue relationnel est peut-être à la base d'une des philosophies de l’auteur de cette réflexion.

@TheLeadingEdge :

J'ai l'impression que c'est un dialogue de sourds.

Ben non, en fait depuis cette discussion, les choses ont le mérite d'être clair au niveau de l'équipe principale de Cake : ils ne l'ont pas fait parce que c'est compliqué et inutile d'après eux ! Même s'ils reconnaissent très légèrement que c'est contraire au modèle relationnel.

La seule solution que je vois pour toi, c'est que tu modélises ta base de façon relationnelle (avec les identifiants naturels -qui leur donnent de l'urticaire- pour sécuriser tes données) et que lorsque tu auras validé ton schéma tu y ajoutes des surrogates keys comme PK partout où c'est nécessaire pour que Cake soit content

Ben oui, c'est ce que je fais maintenant... mais quelle perte de temps si on a beaucoup de tables avec des clés composées !

Est-ce que Cake permet de faire le binding de façon manuelle ?

Oui, je pense, car au-delà de ses aspects "automagic", il reste entièrement personnalisable, on peut donc faire des query à la main en s'affranchissant de sa mécanique, mais si on en passe par là à chaque fois, le framework n'a plus d'utilité !

Ils te proposent de le faire toi-même. A la limite si tu en as la possibilité, pourquoi pas ?
Effectivement ce n'est pas à la couche métier (PHP) de gérer la persistance. Je conçois que se soit compliqué à faire de façon automatique et que ce ne soit pas leur ''tasse de thé'' de se prendre la tête avec des concepts qu'ils ignorent.

Oui, quand je serais un master of Cake, je me lancerai bien dans cette aventure, mais je pense que ce ne sera pas avant plusieurs années

Mais comme le disait Fsmrel hier, ce qui rend le truc plus complexe, c'est qu'il faut pouvoir l'implémenter pour tous les SGBD supportés par Cake et là, c'est très largement au-dessus de mes compétences, car en dehors de MySQL et Postgres je ne les connais pas...

[fsmrel]

Hello Avairet,

Vous n'êtes pas seul à avoir à vous frotter aux staliniens ignorants, bigey3 se retrouve dans votre situation...