Bonjour,
On me demande de créer une vue qui rassemblerait différents objets de notre outil, avec possibilité de créer des liens entre eux (c’est là mon problème).
J’ai fait un objet SELECT, mais je me souviens à l’époque n’avoir pas réussi à le référencer à partir d’un objet persisté.
Avant de chercher une alternative à proposer, vous est-il possible de me confirmer que ce que j’essayais de faire via ce ticket n’est toujours pas faisable?
Quand un utilisateur parle de vue, il parle souvent d’objet métier.
Un objet SELECT n’est pas persistant, c’est un agrégat de données qcq pour visualiser des rapports, pas pour faire des mises à jours ou l’intégrer comme un objet métier au reste du modèle.
Sinon comment créer des foreign-key persistantes vers rien ? Un objet SELECT en mémoire n’a pas de clé fonctionnelle, ni de bijection avec un record unique en base…, Comment gérer les delete cascade ou les lien morts, etc.
Même si le SELECT concerné ramène des row_id uniques qui le relie à un seul record en base, au mieux les jointures seront via des “select de select” très couteuses, au pire Simplicité ou la base n’y comprendra rien.
Bref de mon point de vue, il ne faut pas partir dans ce choix de conception.
Il faut persister ce que fait ce “select” dans un vrai objet métier persistant
alimentation par cron et/ou au fil de l’eau depuis les objets qui gèrent les données sources
avec un row_id + une clé fonctionnelle compréhensible de l’utilisateur
foreign-key classiques / delete cascade, etc.
Par exemple pour un consultant qui facture par CRA :
l’utilisateur saisie des charges par jour
on veut remonter ses charges consolidées par mois
une facture mensuelle référence chaque consolidation
Pour ça, on a besoin d’un objet persistant calculé chaque mois, pas d’un simple SELECT.