Skip site navigation (1) Skip section navigation (2)

Re: Temps de réponse

From: Jean-Paul ARGUDO <jean-paul(at)argudo(dot)org>
To: Eric HAGENBACH <eric(dot)hagenbach(at)vif(dot)tm(dot)fr>
Cc: PG Fr Generale <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Re: Temps de réponse
Date: 2004-07-28 14:27:01
Message-ID: 4107B7B5.5090800@argudo.org (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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

In response to

Responses

pgsql-fr-generale by date

Next:From: Eric HAGENBACHDate: 2004-07-29 14:16:10
Subject: Re: Temps de réponse
Previous:From: Jean-Max ReymondDate: 2004-07-28 14:06:08
Subject: Re: Temps de réponse

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group