Discussion :

[laurentSc]

Bonjour,

comme mon titre l'indique, mon appli gère des fichiers CSV. En gros, elle les lit, les parse, teste la validité du contenu, écrit leur contenu en BDD (si valide), et met en lecture les informations.

Avant d'écrire le contenu en BDD, elle teste le contenu pour vérifier sa validité. Il y a donc 2 accès au contenu du fichier : 1- pour tester la validité et 2- pour écrire en BDD.

Mais problème de conception : au cours du parsage, je vais créer des instances d'objet, que je vais ensuite transmettre aux classes chargées du test de validité et de l'écriture en BDD. Ma question : vaut-il mieux créer une instance par ligne du CSV ou une seule pour le CSV entier ?
Comme le nombre de lignes est variable, je pencherais plutôt par une seule instance pour le fichier entier, mais du coup, l'instance à transmettre va contenir des tableaux (un par type de données contenue dans le CSV) dont le nombre d'éléments sera le nombre de lignes du CSV. Et ces tableaux, il faudra les parcourir 2 fois : 1 fois pour tester la validité et une 2e fois, si c'est valide, pour écrire en BDD. Ca ne me semble pas économique en performance. Y a-t-il une meilleure conception, SVP ?

[CosmoKnacki]

Petite précision: Quand une ligne est incorrecte, que doit-il se passer? Est-ce qu'elle est simplement sautée, puis on continue de traiter les autres ou bien est-ce que l'intégralité du fichier csv est abandonné (et donc aucune insertion n'aura lieu en base de données provenant de ce fichier)?

[laurentSc]

Tu fais bien de poser cette question qui me paraît judicieuse, même si sans y réfléchir, j'avais adopté la 2e option : si une erreur est détectée, aucune écriture en bdd (donc on abandonne le CSV). De toute façon, s'il y a une erreur, l'auteur du CSV devra corriger puis fournir une version corrigée qu'on mettra en bdd. Donc in fine, l'état de la bdd sera identique.

[Soundboy39]

Bonjour,

Si aucune ligne ne doit être insérée en base dans le cas où il y en au moins une ligne en erreur... alors tu n'a pas le choix, il faut faire les choses en 2 temps.

Par contre tu peux te contenter de faire qu’un seul INSERT, tu peux par exemple préparer toutes tes lignes "(nom_colonne_1, nom_colonne_2, ... VALUES ('valeur 1', 'valeur 2', ...)" lors du parcours de validation du fichier, puis les regrouper au moment de faire l'INSERT.

Il y a un exemple ici : https://sql.sh/cours/insert-into
dans le paragraphe "Insertion de plusieurs lignes à la fois"

Alors attention par contre au nombre de ligne par Insert, à vérifier mais il me semble que cela peut être limité... du coup il vaudrait mieux partir sur une répartition des lignes sur plusieurs Insert, en espérant qu'il n'y ait pas une des requêtes qui échoue...

[laurentSc]

Merci pour ta réponse.
D'abord, hier, en répondant à Cosmo, j'ai oublié une précision : même si on détecte une erreur, on continue à balayer les données pour repérer toutes les erreurs dans le CSV. Donc on n'abandonne l'écriture en BDD qu'à la fin du test de validité.

Ensuite, OK pour un seul INSERT (en fait quelques-uns car pour simplifier mon exposé, j'ai parlé d'une seule table adressant le fichier CSV, mais en réalité, je répartis les informations sur 5 tables). En fait (merci de me dire si je me trompe), un ou quelques INSERTS par ligne du CSV, sachant qu'il y aura un enregistrement en BDD par ligne du CSV.

[grunk]

Si tes fichiers sont de taille raisonnable tu peux les parcourir une fois , stocker en mémoire le contenu. Puis faire le test de validité et éventuellement l'insertion sur ce contenu en mémoire.
Ou encore , parcourir le fichier , tester ligne à ligne et stocker en mémoire ce qui est ok , pour éventuellement ensuite insérer.

Ce n'est vaalable que pour des fichiers de quelques Ko à quelque Mo , au delà il faudra les parcourir deux fois , pas le choix.

Pour des gros fichiers on peut imagine ca :
Tu lis ligne à ligne
Tu vérifie la validité
Tu écris la ligne validé dans un nouveau fichier csv.
Tu donne ce fichier csv à mysql pour import si tout est ok.

Note que pour ce genre de travail les generateurs sont top car il permettent de garder la mémoire basse