[Oracle 9i] Chargements de fichiers en tables

**ftrifiro** · 15/01/2007, 16h48

Donc chaque premier enregistrement d'une structure repéré par son type d'enregistrement, je fais un nextval sur la séquence et j'oriente le *loader vers la table_1. Ensuite j'oriente les lignes suivantes vers les tables_2, .._n avec un curval sur la même séquence. C'est bien ça ?

Ca semble pas mal du tout (si j'ai bien compris...).

Au final, je me retrouve avec les tables remplies, par type d'enregistrement, donc avec possibilité de tout regrouper via requête.

**DoRiane** · 15/01/2007, 16h53

sur le principe, c'est ca.

**ftrifiro** · 15/01/2007, 16h53

En théorie c'est ça !
Et en pratique, j'espère aussi

!!

Tu as déjà essayé ce genre de choses ?

**DoRiane** · 15/01/2007, 16h59

le sqlloader vers plusieurs tables oui, la séquence non mais ca doit marché puisque l'on peut utiliser des fonctions dans sqlloader pour formater les valeurs recueilli depuis le fichier plat

**ftrifiro** · 15/01/2007, 17h00

Bon je crois que je vais pas échapper à faire un essai

!!

Merci en tout cas.

**DoRiane** · 15/01/2007, 17h09

Tu nous diras si ca marche

**ftrifiro** · 15/01/2007, 17h10

Oui. Je vous dirai. Maintenant, faut que j'arrive à me faire installer un environnement pour faire ça parce que pour l'instant, j'ai même pas les droits d'admin sur mon poste. Mais ça c'est un tout autre souci !

**Wurlitzer** · 16/01/2007, 09h14

Une petite remarque en passant

Envoyé par DoRiane

Le problème avec la solution du trigger, c'est qu'on ne peut pas mettre à jour la ligne concerné par le trigger dans ce même trigger.

Ah bon ? Tu es sur ? Regarde du coté de :old et :new § Accessing Column Values in Row Triggers dans http://download-uk.oracle.com/docs/c...tr.htm#1006171

Sinon, votre solution avec une séquence en jouant sur le nextval et le curval est dans le sqlloader est rusé.

**ftrifiro** · 16/01/2007, 10h14

Nouveau matin, nouveau chagrin !

Compliquons encore un tout petit peu, désolé... En réfléchissant à mon cas précis, je dois apporter un détail supplémentaire... Dans la structure qui se décrit avec les enregistrements type1, type2, ..., typen, on peut trouver pour disons un même client plusieurs lignes de type2 par exemple...

Sur le principe, vous allez me dire "ben oui et alors ?"...

En fait, du coup, ça veut dire que pour la table type2, je ne peux pas utiliser la séquence comme identifiant à cause de la non unicité. Du coup, comment faire ? Est-il possible d'utiliser cette séquence en clé étrangère et d'avoir une autre clé primaire tout à fait technique pour uniquement garantir l'unicité de chaque tuple ?

Oh nom d'un chien, ai-je été clair ?

Fred

**DoRiane** · 16/01/2007, 10h24

Ah bon ? Tu es sur ? Regarde du coté de :old et :new § Accessing Column Values in Row Triggers dans http://download-uk.oracle.com/docs/c...tr.htm#1006171

Autant pour moi

Pour la peine,

Code :

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

1
2
3
4
5
6
7
8
 
CREATE OR REPLACE TRIGGER T_TEST AFTER
INSERT ON TEST_TEMP
DECLARE
BEGIN
	UPDATE TEST_TEMP SET TEST_ID = UTIL_ID.NEXTVAL WHERE TEST_ID IS NULL;
END;
/

voici un trigger qui fait ce qu'on lui demande

**kalyparker** · 16/01/2007, 10h30

Nouveau matin, nouveau chagrin !

La vie n'étant pas un long fleuve tranquille alors ...

En fait, du coup, ça veut dire que pour la table type2, je ne peux pas utiliser la séquence comme identifiant à cause de la non unicité. Du coup, comment faire ? Est-il possible d'utiliser cette séquence en clé étrangère et d'avoir une autre clé primaire tout à fait technique pour uniquement garantir l'unicité de chaque tuple ?

Tu peux utiliser effectivement utiliser la séquence principale (qui fait le lien avec les clients) comme clé étrangère et ajouter une nouvelle séquence pour la table type2. Le principe est le même.
L'essentiel c'est que tu retrouve tes petits !

**ftrifiro** · 16/01/2007, 10h38

Je me demandais si ça marcherait en fait, mais je crois que trève de théorie, il faut que je fasse des essais... Dès que j'ai les droits d'admins sur ce

de poste

!

**Wurlitzer** · 17/01/2007, 08h04

Envoyé par ftrifiro

Nouveau matin, nouveau chagrin !

En fait, du coup, ça veut dire que pour la table type2, je ne peux pas utiliser la séquence comme identifiant à cause de la non unicité. Du coup, comment faire ? Est-il possible d'utiliser cette séquence en clé étrangère et d'avoir une autre clé primaire tout à fait technique pour uniquement garantir l'unicité de chaque tuple ?

Il suffit juste de dupliquer ce que tu as fais pour ta table de type1 créer autre une sequence (tu peux en créer autant que tu veux sous Oracle). Dans la création des enregistrements de type2 tu auras seq1.currval pour ta clé étrangère sur la table de type1 et seq2.nextval pour ta clé primaire.

EDIT:

Pas bien reveillé ce matin. J'avais pas vu la réponse de kalyparker. Enfin vaut mieux deux reponses que pas du tout...

**ftrifiro** · 18/01/2007, 10h48

Oui en plus c'est la même réponse, donc c'est extrêmement encourageant

Merci.

**ftrifiro** · 18/01/2007, 16h21

Ma structure

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
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
* suppression des tables */
DROP TABLE T_EN1;
DROP TABLE T_EN2;
DROP TABLE T_EN3;
 
/* suppression des séquences */
DROP SEQUENCE S_EN1;
DROP SEQUENCE S_EN2;
DROP SEQUENCE S_EN3;
 
/* création des séquences */
CREATE SEQUENCE S_EN1 START WITH 1 INCREMENT BY 1 MAXVALUE 9999;
CREATE SEQUENCE S_EN2 START WITH 1 INCREMENT BY 1 MAXVALUE 9999;
CREATE SEQUENCE S_EN3 START WITH 1 INCREMENT BY 1 MAXVALUE 9999;
 
/* création des tables */
CREATE TABLE T_EN1(
	ID	NUMBER(7)	NULL,
	TITRE	VARCHAR2(3)	NULL,
	NOM	VARCHAR2(12) 	NULL,
	PRENOM  VARCHAR2(12) 	NULL);
 
CREATE TABLE T_EN2(
	ID	NUMBER(7)	NULL,
	ADRESSE	VARCHAR2(40)	NULL,
	ID_TEN1	NUMBER(7)	NULL);
 
CREATE TABLE T_EN3(
	ID	NUMBER(7)	NULL,
	DATEC	VARCHAR2(10)	NULL,
	LIBC	VARCHAR2(6)	NULL,
	ID_TEN1	NUMBER(7)	NULL);
 
COMMIT;

Mon fichier de contrôle

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
22
23
24
25
26
 
LOAD DATA INFILE 'coplatest.txt'
TRUNCATE
INTO TABLE T_EN1 
	WHEN (1:3) = 'EN1' 
	(  
		ID	"S_EN1.NEXTVAL",
		TITRE	POSITION(4:6)	CHAR,          
		NOM	POSITION(7:18)	CHAR,
		PRENOM	POSITION(19:30)	CHAR
	)
INTO TABLE T_EN2 
	WHEN (1:3) = 'EN2' 
	(  
		ID	"S_EN2.NEXTVAL",
		ADRESSE	POSITION(4:43)	CHAR,
		ID_TEN1	"S_EN1.CURRVAL"
	)
INTO TABLE T_EN3 
	WHEN (1:3) = 'EN3' 
	(  
		ID	"S_EN3.NEXTVAL",
		DATEC	POSITION(4:13)	CHAR,
		LIBC	POSITION(14:19)	CHAR,
		ID_TEN1	"S_EN1.CURRVAL"	
	)

Mon fichier de données

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
EN1M  DURAND     FABIEN      
EN24 RUE DES ARBRES 60400 LA BAS
EN312/08/2005ACHAT 1
EN322/11/2006ACHAT 2
EN4
EN1M  DUPONT     FRED
EN255 RUE DES FLEURS 63000 ALACAMPAGNE
EN301/05/2002ACHAT 3
EN317/10/2003ACHAT 4
EN304/01/2007ACHAT 5
EN4

Seulement voilà, si tout semble s'exécuter normalement, j'ai de mauvaises surprises lorsque je fais des SELECT sur les trois tables. Tous les enregisrements des tables T_EN2 et T_EN3 sont rattachées au même T_EN1. A se demander si l'utilisation des séquences telle qu'on l'a imaginée est correcte... Ou alors une lecture non séquentielle des lignes du fichier

Auriez-vous des idées au vue du code ci-dessus ?

Merci, Frédéric

**Wurlitzer** · 18/01/2007, 16h49

J'avais pas pensée a ça

! !

Je suis pas un pro de SQL*Loader mais voila ce que j'en déduis et comment contourner le problème

SQL*Loader est prévu pour faire de chargement de masse. Il est donc optimisé et en particulier c'est plus efficace de faire un insert qui insert 50 lignes en une fois que 50 inserts individuels.

Ce que fait donc le SQL*LOADER c'est garder en memoire toute les lignes de type1 pour les inserer ensemble, idem pour le type2, etc dans la limite de la mémoire disponnible. Et donc meme si SQL*LOADER lit bien le fichier sequentiellement il ne fait pas les inserts dans le meme ordre.

Pour contourner cela tu peux positionner le parametres rows à 1. Dans ce cas tu forces SQL*Loader à inserer les lignes une par une et donc dans l'ordre de lecture du fichier. Par contre tu vas perdre en perf mais c'est peut etre pas un problème pour toi.

Hope this helps

**ftrifiro** · 18/01/2007, 16h51

Ah oui mais si les fichiers sont gros, ça va être terrible un commit à chaque ligne non ? Mince, c'est vraiment dommage ça..

Mais effectivement avec le rows=1, ça fonctionne.......... Ce qu'il faudrait, c'est contraindre SQL*Loader à lire le fichier séquentiellement, mais ce ne doit pas être possible... Moi et mes besoins tordus aussi

!!

D'autres idées ?

**kalyparker** · 18/01/2007, 16h56

Est ce que les autres séquences fonctionnent ?

**ftrifiro** · 18/01/2007, 17h05

Si je fais un commit à chaque ligne, les séquences fonctionnent de façon normales oui. Sinon, précédemment, sans l'option rows=1, c'était anarchique au niveau des numéros générés et des associations via les currval.

En fait, je suis pas sûr d'avoir compris ta question