Referencer (encore) un objet SELECT?

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?

Merci !
Emmanuelle

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.