Discussion :

[dragon74]

Hello,

Lorsque je reçois des fichiers input en entrée, j'hésite toujours entre les charger avec un sql*Loader ou bien définir une table externe. Y a-t-il des best practices à ce niveau? Pourquoi employer une solution plutôt qu'une autre?

Merci

[Pomalaix]

Moi je dirais au passage "pourquoi parler français quand le franglais est d'un si bel effet ?"

Sur le plan technique, c'est simple.
Si vos fichiers de données continuent à être modifiés au fil de l'eau, et sont simplement lus (mais pas modifiés) par Oracle, alors c'est la table externe qui répond au besoin. Exemple : lecture d'un alert.log par SELECT.

Pour les autres cas, il faut charger les données en table pour en obtenir tous les avantages : possibilité de modifier les données, de les sauvegarder comme toutes les autres tables, obtention des performances normales d'une structure relationnelle.

[PpPool]

je rajouterai aussi au post de Pomalaix qu'il faut considérer que les tables externes ne peuvent être indexées.

cela m'a valu une mauvaise expérience par le passé.

c'est vrai que cela parait être tip top les EXTERNAL TABLES mais il faut bien étudier le contexte fonctionnel et applicatif qui va attaquer ce genre de table en SQL

[dragon74]

Désolé pour le franglais Pomalaix mais je n'ai pas réussi à traduire le terme correctement.

[Pomalaix]

Désolé pour le franglais Pomalaix mais je n'ai pas réussi à traduire le terme correctement.

Hello --> bonjour, salut
fichiers d'input en entrée --> fichiers de données, fichiers en entrée
best practices --> bonnes pratiques, règles de l'art


Facile non ?

[dragon74]

Hello --> bonjour, salut
fichiers d'input en entrée --> fichiers de données, fichiers en entrée
best practices --> bonnes pratiques, règles de l'art


Facile non ?

En effet...
Je te propose de venir travailler quelques mois en Belgique. On verra si ce sera toujours aussi facile

[deadoralive]

Pomalaix, à mon avis tu ne réponds pas à la question. Sqlloader ou les tables externes permettent de charger des tables oracles.

avantage des tables externes:
syntaxe sql connue et performante, donc un seul langage à connaitre

inconvénient
les fichiers définis comme table externes doivent être accessibles dans une directory Oracle, à priori pas sur un poste client, il faudra copier les fichiers sur le server probablement alors que sqlloader peut s'exécuter en client server

[Pomalaix]

Pomalaix, à mon avis tu ne réponds pas à la question. Sqlloader ou les tables externes permettent de charger des tables oracles.

Je ne suis pas certain qu'on utilise les mots dans le même sens.
Quand je dis charger une table, je veux dire qu'on alimente une fois pour toutes une table ordinaire, et qu'on peut donc ensuite supprimer le fichier de données, dont on n'a plus besoin.

avantage des tables externes:
syntaxe sql connue et performante, donc un seul langage à connaitre

Euh, je ne vois pas en quoi ça distingue les tables externes. Avec les tables externes, vous émulez le SELECT ; avec les tables normales, vous utilisez tout le DML que vous voulez.

Pour moi il n'y a pas photo : on ne doit utiliser une table externe que si une table ordinaire ne convient pas. A mon sens, les cas sont rares, le principal étant lorsque le fichier de données doit continuer à être accédé (en lecture ou en écriture) par un mécanisme externe à la base de données,

[deadoralive]

Je vais essayer d'être plus clair.

Le problème est de lire des données externes (fichiers plats) pour alimenter des tables oracle. Je n'ai jamais dit que je voulais définir une table externe à la place d'une table standard d'oracle, la table externe ne sert que pour alimenter une/des tables standard

On peut utiliser sqlloader qui a sa syntaxe propre ou définir le fichier comme une table externe et alimenter les tables 'internes' de la base et là on utilise du sql ou plsql avec toutes les possibiltés du langage (when, case, manipulations de chaine de caractéres etc...), on peut meme faire des jointures avec des tables standard, pour valider ou transformer des données.

Souvent avec sqlloader on charge dans une table de travail, et on manipule les données ensuite en sql, alors qu'en définissant une table externe on peut économiser une étape et de la place.

J'ai utilisé quelquefois sqlloader et la syntaxe me semblait moins évidente que du sql. L'avantage du sql est qu'on l'utilise plus souvent que sqlloader, et à priori on le maitrise mieux. J'ai l'impression que l'on peut faire plus de choses avec sql, mais comme je n'ai pas utilisé loader depuis longtemps si quelqu'un peut confirmer ou infirmer ?

L'avantage d'utiliser des procédures en Pl c'est que l'on peut utiliser des pipes.

Pour moi, on doit utiliser les tables externes si c'est possible.

[Pomalaix]

Je vais essayer d'être plus clair.

Le problème est de lire des données externes (fichiers plats) pour alimenter des tables oracle. Je n'ai jamais dit que je voulais définir une table externe à la place d'une table standard d'oracle, la table externe ne sert que pour alimenter une/des tables standard

Je comprends qu'on ne se comprenne pas, ce n'est pas du tout dans ce sens que j'avais interprété la question initiale de Dragon74.

On peut utiliser sqlloader qui a sa syntaxe propre ou définir le fichier comme une table externe.

Sauf que la syntaxe permettant de créer une table externe ne tombe pas du ciel, et a une fâcheuse tendance à ressembler (et pour cause !) à du SQL*Loader :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CREATE TABLE emp_load (first_name CHAR(15),
                      last_name CHAR(20),
                      year_of_birth INT,
                      phone CHAR(12),
                      area_code CHAR(3),
                      exchange CHAR(3),
                      extension CHAR(4))
  ORGANIZATION EXTERNAL
  (TYPE ORACLE_LOADER
   DEFAULT DIRECTORY ext_tab_dir
   ACCESS PARAMETERS
     (FIELDS RTRIM
            (first_name (1:15) CHAR(15),
             last_name (*:+20),
             year_of_birth (36:39),
             phone (40:52),
             area_code (*-12: +3),
             exchange (*+1: +3),
             extension (*+1: +4)))
   LOCATION ('foo.dat'));

Donc je ne crois pas que la facilité syntaxique (qui dépend pour beaucoup de la familiarité qu'on a avec ladite syntaxe) soit un critère décisif.

Mais vous allez être content : Tom Kyte semble être un partisan des tables externes, et expose divers arguments ici : http://asktom.oracle.com/pls/asktom/...:6611962171229

[dragon74]

En fait, je me demandais s'il y avait une raison de choisir une solution plutôt qu'une autre entre un sqlloader et une table externe.

Etant de la "vieille école", j'ai toujours été habitué au sqlloader. Ayant eu le choix dans quelques projets entre les 2 solutions, j'ai repris la "vieille méthode" mais je me dis qu'il y a des cas où employer des tables externes doit être plus intéressant.

[Invité]

Tout est dit ici :

Si vos fichiers de données continuent à être modifiés au fil de l'eau, et sont simplement lus (mais pas modifiés) par Oracle, alors c'est la table externe qui répond au besoin. Exemple : lecture d'un alert.log par SELECT.

Pour les autres cas, il faut charger les données en table pour en obtenir tous les avantages : possibilité de modifier les données, de les sauvegarder comme toutes les autres tables, obtention des performances normales d'une structure relationnelle.

[deadoralive]

Sauf que la syntaxe permettant de créer une table externe ne tombe pas du ciel, et a une fâcheuse tendance à ressembler (et pour cause !) à du SQL*Loader :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CREATE TABLE emp_load (first_name CHAR(15),
                      last_name CHAR(20),
                      year_of_birth INT,
                      phone CHAR(12),
                      area_code CHAR(3),
                      exchange CHAR(3),
                      extension CHAR(4))
  ORGANIZATION EXTERNAL
  (TYPE ORACLE_LOADER
   DEFAULT DIRECTORY ext_tab_dir
   ACCESS PARAMETERS
     (FIELDS RTRIM
            (first_name (1:15) CHAR(15),
             last_name (*:+20),
             year_of_birth (36:39),
             phone (40:52),
             area_code (*-12: +3),
             exchange (*+1: +3),
             extension (*+1: +4)))
   LOCATION ('foo.dat'));

Donc je ne crois pas que la facilité syntaxique (qui dépend pour beaucoup de la familiarité qu'on a avec ladite syntaxe) soit un critère décisif.

Je parlais de la syntaxe pour lire les données, évidemment pour créer la table, il faut utiliser une nouvelle syntaxe, mais ensuite on se retrouve en terrain connu.

Mais vous allez être content : Tom Kyte semble être un partisan des tables externes, et expose divers arguments ici : http://asktom.oracle.com/pls/asktom/...:6611962171229

effectivement, un autre lien aussi
http://download.oracle.com/docs/cd/B....htm#sthref519

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Choosing External Tables Versus SQL*Loader
 
The record parsing of external tables and SQL*Loader is very similar, so normally there is not a major performance difference for the same record format. However, due to the different architecture of external tables and SQL*Loader, there are situations in which one method is more appropriate than the other.
 
In the following situations, use external tables for the best load performance:
 
    *
 
      You want to transform the data as it is being loaded into the database.
    *
 
      You want to use transparent parallel processing without having to split the external data first.
 
However, in the following situations, use SQL*Loader for the best load performance:
 
    *
 
      You want to load data remotely.
    *
 
      Transformations are not required on the data, and the data does not need to be loaded in parallel.

J'ai eu l'occasion d'utiliser des tables externes, avec du Plsql, c'est vraiment très confortable.