Différence entre traitement et interface ? [Résolu]

[Bizoo]

Bonjour alors voila mon problème j'ai une grosse grosse requête à modéliser avec sunopsis pour mapper des données de 15 tables vers 1 seule autre.
En utilisant les interfaces, cela devient très rapidement extrêmement lourd dans le schéma du aux nombreuses jointures et conditions et je ne parle même pas du temps que ça prend pour ajouter des choses lorsque l'on à déjà fait la moitié de l'interface ... (environ 3 à 5 min d'attente pour l'ajout d'une table supplémentaire à utiliser sans faire les jointures !...)

Je me demandais si ce n'étais pas exactement la même chose de faire un nouveau traitement et en copiant/collant ma requête point barre ...
Çà serait énormément gagnant en temps de cette façon la !

Pouvez-vous me dire si ça change quelque chose de faire d'une façon ou de l'autre ?!?! Et si oui qu'est ce qui change exactement ?

Merci d'avance !

[shaun_the_sheep]

Bonjour,

Tout l'interet d'un ETL est de faire le moin possible de code SQL d'ou les interfaces. De plus pour la maintenance c'est plus facile.

Cherche à fragmenter ton interface et alimente ta table cible en plusieur fois.

[doc malkovich]

Pour ma part, je préfère utiliser plusieurs interfaces qu'un traitement générique car sinon on perd les dépendances entre les tables, et le traitement n'apparait pas dans les analyses d'impact, ou dans les requêtes sur le référentiel.
Et par expérience, on oublie régulièrement ce genre de petit traitement lorsqu'il ya un problème

( je préfère aussi utiliser plusieurs interfaces avec des tables intermédiaires plutôt qu'une vue pour la même raison, de mémoire c'est d'ailleurs une préco de l'éditeur )

[cell]

je suis d'accord avec jhon, il est préférable d'utiliser des interfaces, la représentation graphique pêrmet de visualiser d'un coup ce qui se fait.
Par contre l'utilisation de vue peux être pratique.

[coucou_tt_le_monde]

Ben moi je suis pas tout à fait d'accord
On utilise parfois des traitements pour des TRES grosses requêtes compliquées. C'est plus facile à mettre en place, plus facile à maintenir ...

Après il est toujours possible de faire plusieurs interfaces avec des tables temporaires mais c'est plus compliqué à gérer je trouve. POur ex, j'ai une appli avec 10 interfaces alors qu'un traitement aurait suffit .... ben quand ça évolue, bonjour la galère ! et chaque fois que j'ai une nouvelle ressource et qu'elle doit modifier ce bout de code j'ai des bugs à chaque coup!

Et généralement quand on a un traitement, lors des analyses d'impacts ... on le sait ... (enfin perso mon traitement avec récupération je l'oublie pas )

Après bon ce traitement intègre aussi l'exécution de certaines parties de SQL sous certaines conditions d'option, c'est ce qui nous a poussé à passer par le traitement, mais avec le recul j'apprécie car c'est très simple à maintenir et à débugger.