Re: Temps de réponse

Eric HAGENBACH wrote:
> En fait, la construction de la vue est fait par un script psql et
> dedans il n'est pas précisé le type 'text' dans la condition (c'est le
> script Oracle qui a été adapté pour fonctionner avec Postgres).
> Toute la base de données à ainsi été conçue par migration d'une base
> Oracle vers une base Postgres (notamment en utilisant l'outil ora2pg.pl)
> ainsi tous les champs en varchar2 d'Oracle sont passés en character
> varying chez Postgres.

Quel rapport entre « text » et « varchar2 » ?

Vous insinuez qu'ora2pg transforme les VARCHAR2 d'Oracle en Text sous PG?...

Si oui, donnez un exemple.. Ça peut être un VARCHAR2 extrèmement gros?...

>> On ne le dira jamais assez, mais les choix de conceptions sont
>> primordiaux pour la bonne tenue de la base de données. Ce n'est pas pour
>> rien qu'il y a plusieurs types de données disponibles, encore faut-il
>> s'en servir !

Remarque on ne peut plus sensée!... Il faut toujours choisir le type de
données le plus approprié à l'utilisation. C'est une règle simple,
domage qu'on l'oublie trop! :-)

> La base oracle est déjà installée chez des clients et la base Postgres
> doit suivre la même structure. Nous avons un logiciel écrit en java qui
> attaque les 2 bases, donc les modifs de structure doivent être minimes.

Certes. Mais votre base Oracle côté client est-elle tunée, ne serait-ce
qu'un peu?...

Pouvez vous nous fournir le Oracle.ini de l'instance Oracle en question?

Mieux, un OraSnap en ligne? (http://www.oracle-books.com/orasnap/)

> Quand à l'utilisation du driver ODBC, c'est pour l'instant la seule
> solution qu'on ait trouvée quand on passe par des outils du marché sous
> windows (Cognos et MS olap) pour attaquer Postgres, et encore il y a
> pas mal de paramétrage à mettre en ouvre par exemple pour le requêteur
> de chez Cognos (merci le support Cognos pour son aide, par contre pour
> Microsoft c'est plus flou !!).

Votre PG est sous linux, ou sous windows. Sous windows en Natif (oui
c'est déjà possible, en version de dev bien sur...) ou sous CygWin?..

> Pour en revenir la structure, seule la jointure externe entre la table
> principale et une table annexe avec des champs de types "chaine de car"
> et "numérique" est peut-être inadéquate mais bon il s'agit d'une
> jointure classique entre une entête de facture et le détail de la
> facture.

Peut être "classique" au sens métier pour vous. Reste que ce n'est pas
bien, PG est obligé de caster (::TEXT)...

La conception de votre schéma semble pour le moins curieuse, non?

> Les autres jointures se font par un seul champs de type
> numérique (genre id).

Pourquoi les autres et pas la précédente? :-/

> Il s'agit d'une représentation classique en étoile

Bien des physiques ont cette tête en effet, ça ne préjuge de rien dans
votre cas.

> En espérant avoir été plus clair sur le contexte d'utilisation de ces
> requêtes.

Comme on vous l'a déjà dit, un EXPLAIN avec un bout de schéma est
largement plus explicatif pour nous pour vous aider.

> Rq: Le but final de passer d'une base Oracle vers une base Postgres est
> bien entendu de faire baisser les coûts

Dans un 1er temps, on vient toujours à PG pour cela, comme pour tous les
autres logiciels libres. Je pense qu'après qques mois d'utilisation, cet
argument là sera minime par rapport à d'autres...

> Et Postgres a été choisi par
> rapport à Mysql à cause des vues qui ne sont pas gérées dans cette
> dernière, pour le moment

Sans troller (une fois de plus). Vu la tête de vos requetes, oubliez
direct MySQL, et pas seulement pour les vues hein.... :-))

Cordialement,

--
JP ARGUDO