Import d'une table trop longue ( x heures)

Hello :)

J'ai l'impression que plus j'utilise la fonction d'import de données, plus c'est long

Y a t-il un système de cache ou quelque chose du genre qui fait que l'import de ma table de 30 000 rows prenne 3min la première fois, puis 1h la 3eme ou 4eme fois (je recommence plusieurs fois la même table car je ne connais pas encore très bien les bons types à paramétrer)

ma config : ryzen5 3600 3.9 ghz
16go RAM
(je précise car je suis en local)

Comment faire pour aller plus vite lors d'un import via fichier .csv ? (paramètre SSH peut être ?)

J'ai songé à redémarrer le service par exemple je ne sais pas si ça servirait... (ça semble fonctionner, mais pourquoi ?)

ps : j'utilise mysql workbench

Bonjour,
Il faudrait connaitre la structure de la table (colonnes, clé, indexes, contraintes), le moteur utilisé (myISAM, InnoDB, autre), le sous-système disque.
Bref il nous manque pas mal d'infos.

Tatayo.

Code:

---

1 2 3 4 5 6 7 8 9

CREATE TABLE Localite ( localite_id INT AUTO_INCREMENT NOT NULL, num_voie INT, nom_voie CHAR(200) NOT NULL, cp char(10) NOT NULL, commune CHAR(100) NOT NULL, dpt_id char(10) NOT NULL, commune_id SMALLINT NOT NULL, PRIMARY KEY (localite_id)

---

InnoDB
SSD 870 Qvo

Bonjour,

Si c'est toujours le même fichier qui est chargé, il faut activer l'option REPLACE pour annuler et remplacer le contenu, sinon, toutes les lignes pour lesquelles une contrainte unique est violée est mise à l'écart, ce qui prend du temps.
Autre solution : vider la table par un truncate et la charger.

Par ailleurs, cette table a une structure bien curieuse pour ne pas dire plus :

• Avoir à la fois le libellé de la commune et son identifiant n'est pas normal, seul l'identifiant devrait être présent pour permettre de faire une jointure vers la table des communes et éviter ainsi les redondances
• Il en va de même pour le département qui n'a rien à faire dans cette table. On devrait trouver l'identifiant du département comme FK de la table des communes, permettant de faire la jointure avec la table des départements.
• L'identifiant du département ne devrait pas être un char(10) mais un small integer.
• De plus, le nom de la voie en char(200) est un mauvais choix, du varchar(38) comme le prévoit la norme de la poste doit suffire.
• Et il manque le type de voie (boulevard, rue, impasse, etc.)

Bonjour,

Citation:

---

Envoyé par escartefigue

cette table a une structure bien curieuse pour ne pas dire plus

---

Je me suis fait la même réflexion. Toutefois, il s'agit d'une table destinée à recevoir le contenu d'un fichier importé.
Rien ne dit que cette table ne sert pas uniquement de stockage temporaire et que ces données ne seront pas transférées ensuite dans des tables à la structure plus normalisée.

Citation:

---

Envoyé par al1_24

Bonjour,



Je me suis fait la même réflexion. Toutefois, il s'agit d'une table destinée à recevoir le contenu d'un fichier importé.
Rien ne dit que cette table ne sert pas uniquement de stockage temporaire et que ces données ne seront pas transférées ensuite dans des tables à la structure plus normalisée.

---

Citation:

---

Envoyé par escartefigue

Bonjour,

Si c'est toujours le même fichier qui est chargé, il faut activer l'option REPLACE pour annuler et remplacer le contenu, sinon, toutes les lignes pour lesquelles une contrainte unique est violée est mise à l'écart, ce qui prend du temps.
Autre solution : vider la table par un truncate et la charger.

Par ailleurs, cette table a une structure bien curieuse pour ne pas dire plus :

• Avoir à la fois le libellé de la commune et son identifiant n'est pas normal, seul l'identifiant devrait être présent pour permettre de faire une jointure vers la table des communes et éviter ainsi les redondances
• Il en va de même pour le département qui n'a rien à faire dans cette table. On devrait trouver l'identifiant du département comme FK de la table des communes, permettant de faire la jointure avec la table des départements.
• L'identifiant du département ne devrait pas être un char(10) mais un small integer.
• De plus, le nom de la voie en char(200) est un mauvais choix, du varchar(38) comme le prévoit la norme de la poste doit suffire.
• Et il manque le type de voie (boulevard, rue, impasse, etc.)

---

Eh bien écoutez messieurs, vous irez chercher votre chèque auprès d'open classrooms car vous êtes en train de corriger mon travail à leur place :lol:

En effet je suis encore un fœtus qui apprend tout juste à remplir une base de donnée, il est donc normal que vous trouviez ce genre d'imperfections...

concernant le REPLACE, je ne m'en suis pas servi car j'ai directement drop la table depuis le schéma avec un clique droit. Est-ce différent de REPLACE ?

Vous avez raison je vais faire une table commune, ça fera 4 tables au lieu de 3 sur mon MPD ce sera moins redondant que d'avoir 7 colonnes par table...

id département en char car il existe des départements avec des lettres.
type de voie je vois pas l’intérêt de le préciser il s'agit juste d'une modélisation des valeurs foncières des biens vendus en 2020, rue numéro de voie et commune me permette d'identifier le bien de manière unique.

Puisque vous insistez, voici donc mon MPD
Pièce jointe 602149

j'ai laissé volontairement la table localite

le problème en créant ces tables commune et département, c'est que ma table localité se retrouve avec 2 attributs à caser que je ne sais pas où foutre :
num_voie
nom_voie
-> encore une 5eme table ? que je vais appeler comment du coup ? bourbier

Et créer une table département avec une colonne.. créer une table pour une table bof

Vous comprenez donc que je fasse une table localité qui regroupe tout ces paramètres géographiques.

Avec un numéro et un nom de voie, je vois bien une table Adresse, par exemple ;)

Tatayo

Citation:

---

Envoyé par tatayo

Avec un numéro et un nom de voie, je vois bien une table Adresse, par exemple ;)

Tatayo

---

Un peu comme ça donc ?
Pièce jointe 602150

Et oui j'en profite !

Heu.. Non.
Une adresse est liée à une commune, qui est liée à un département (voir à un pays).
Tu dois donc avoir l'id de l'adresse dans la table des biens, l'id de la commune dans la table Adresse et l'id du Département dans la table Commune.

Tatayo.

P.S. une adresse "normalisée" en France possède 4 lignes, et non 2 comme dans ton schéma.

Citation:

---

Envoyé par tatayo

P.S. une adresse "normalisée" en France possède 4 lignes, et non 2 comme dans ton schéma.

---

Euh si je transforme encore mes tables j'en fini pas je vais me retrouver avec :

une table adresse :

- num voie
- nom voie
-type voie (qui me sert à rien, comme dis plus haut)
-id commune

puis une table commune avec id commune... ça n'a aucun sens

Je suis à cheval entre données importantes et normalisation de schéma...

voici à quoi devrait ressembler le modèle conceptuel des données (MCD) :

Pièce jointe 602163

De ce modèle conceptuel, on dérive le modèle logique qui suit :

Pièce jointe 602164

Qui donne le script qui suit si le SBGD choisi est MySQL :

Code:

---

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 36 37 38

CREATE TABLE DP_département( DP_ident INT AUTO_INCREMENT, DP_numero CHAR(3) NOT NULL, DP_nom VARCHAR(50) NOT NULL, PRIMARY KEY(DP_ident), UNIQUE(DP_numero) );   CREATE TABLE CO_commune( DP_ident INT, CO_ident SMALLINT, CO_insee CHAR(5) NOT NULL, CO_nom VARCHAR(50) NOT NULL, PRIMARY KEY(DP_ident, CO_ident), FOREIGN KEY(DP_ident) REFERENCES DP_département(DP_ident) );   CREATE TABLE AD_adresse( AD_ident INT AUTO_INCREMENT, AD_ligne1 VARCHAR(38), AD_ligne2 VARCHAR(38), AD_ligne3 VARCHAR(50), AD_ligne4 VARCHAR(50), AD_ligne5 VARCHAR(50), DP_ident INT NOT NULL, CO_ident SMALLINT NOT NULL, PRIMARY KEY(AD_ident), FOREIGN KEY(DP_ident, CO_ident) REFERENCES CO_commune(DP_ident, CO_ident) );   CREATE TABLE BI_bien( BI_ident INT AUTO_INCREMENT, BI_carrez DECIMAL(5,2) NOT NULL, BI_nb_piece SMALLINT NOT NULL, AD_ident INT NOT NULL, PRIMARY KEY(BI_ident), FOREIGN KEY(AD_ident) REFERENCES AD_adresse(AD_ident) );

---