+ Répondre à la discussion Actualité déjà publiée
Affichage des résultats 1 à 19 sur 19
  1. #1
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut Les fichiers CSV avec Java

    Le format CSV est, aujourd'hui encore, largement utilisé. Il fait le bonheur des équipes de développement car il est simple à manipuler. La lecture d'un fichier au format CSV demande toutefois un certain nombre de compétences.

    Je propose ici un article qui aborde les points clés à maîtriser, pas à pas avec une difficulté progressive, pour savoir traiter le célèbre CSV. Il y aurait beaucoup de choses à ajouter, notamment à propos des fichiers volumineux, mais l'essentiel est là pour bien commencer.

    L'article se trouve à l'adresse suivante : http://thierry-leriche-dessirier.dev...csv-avec-java/

    Tous les commentaires, surtout ceux qui disent du bien et m'encouragent (lol), sont les bienvenus.

    Bonne lecture.

  2. #2
    Membre Expert Avatar de Jidefix
    Profil pro
    Inscrit en
    septembre 2006
    Messages
    724
    Détails du profil
    Informations personnelles :
    Âge : 29
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations forums :
    Inscription : septembre 2006
    Messages : 724
    Points : 1 006
    Points
    1 006

    Par défaut

    Bonjour,
    je n'ai pas été jusqu'en bas, mais ai été surpris de voir que Excel ne modifiait pas les fichiers .csv.
    Là où je travaille nous avons justement eu pas mal de problème avec des fichiers CSV ouverts avec Excel (2000 et 2003), où apparaissent subitement des guillemets autour des champs, où les dates changent de format, où des 0 deviennent des 0.0...
    Je ne sais pas ce qu'il en est d'Excel 2007 et 2010 mais il me semble important de le mentionner!
    Veuillez agréer nos sentiments les plus distingués. Soyez assurés de notre entière collaboration, bien à vous pour toujours et à jamais dans l'unique but de servir l'espérance de votre satisfaction, dis bonjour à ton père et à ta mère, bonne pétanque, mets ton écharpe fais froid dehors.

  3. #3
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Effectivement je n'ai pas testé sur les vieilles versions d'Excel. Les captures ont été faites sur 2010. Du coup ma remarque sur Open office est peut-être également valable pour Excel 2003.

  4. #4
    Membre du Club
    Profil pro Thibaud Vibes
    Inscrit en
    juin 2008
    Messages
    13
    Détails du profil
    Informations personnelles :
    Nom : Thibaud Vibes

    Informations forums :
    Inscription : juin 2008
    Messages : 13
    Points : 40
    Points
    40

    Par défaut

    Merci pour ce tuto complet sur les CSV.

    Il est vrai que ces fichiers sont plus légers que des fichiers XML mais selon moi ils sont infiniment plus compliqués du fait de l'absence de règles. Prendre en compte tous les cas se révèle complexe comme le montre votre tutorial finalement (16 paragraphes quand même).
    Au moins avec le XML il y a les DTD ou les XSD qui permettent de vérifier l'intégrité du fichier avant la lecture.

    Toutes les applications proposent des export CSV mais jamais sous la même forme (séparateur duifférents, pas de protections, ...) et au final c'est pénible à intégrer. Combien d'imports plantent en plein milieu parce que notre parseur de fichier CSV ne prend pas tout en charge?

    Enfin, je trouve dommage que la notion d'encodage des caractères ne soit pas évoquée bien que la problématique soit plus large que la lecture de fichiers CSV. C'est très souvent une source de problèmes.
    Le code proposé n'est donc pas 100% portable (NB: je n'ai pas téléchargé le .zip) puisque les classes "bas niveau" utilisées pour lire le fichier vont s'appuyer sur l'encodage par défaut de la JVM. En tout cas j'espère que vos élèves sont sensibilisés, sinon j'imagine bien leur déconvenue lorsqu'ils reprendront vos sources pour lire un fichier CSV encodé en UTF-8, sous Windows...

  5. #5
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Effectivement l'article pourrait encore traiter un grand nombre de choses. Quand j'ai réalisé qu'il y avait autant de pages, j'ai reporté ces ajouts pour une prochaine version. J'avoue toutefois que je n'avais pas pensé à l'encoding.

    Le format CSV possède un avantage sur le XML, c'est son poids. En effet, lorsqu'il y a des millions de lignes, ça fait une grosse différence. Dans tous les cas, avec les fichiers volumineux, on utilise des techniques qui ne sont pas présentées dans l'article.

  6. #6
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 725
    Points : 6 918
    Points
    6 918

    Par défaut

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
     
    public static List<String> readFile(File file) {
     
            List<String> result = new ArrayList<String>();
     
            FileReader fr = new FileReader(file);
            BufferedReader br = new BufferedReader(fr);
     
            for (String line = br.readLine(); line != null; line = br.readLine()) {
                result.add(line);
            }
     
            br.close();
            fr.close();
     
            return result;
    }

    La méthode close() d'un stream ou d'un reader appelle automatiquement les méthods close() de ses enfants, conformément au pattern decorator. Donc vous ne devriez pas faire fr.close() car la ressource est déjà fermée et suivant les implémentations, vous pourriez vous manger une IOException.

    Par ailleurs votre boucle peut s'écrire

    Code :
    1
    2
    3
    4
    5
     
    while( (String line = br.readLine()) != null ) 
    {
       ...
    }

    Je lirai plus en détails ce soir ou demain.

    Il est vrai que ces fichiers sont plus légers que des fichiers XML mais selon moi ils sont infiniment plus compliqués du fait de l'absence de règles. Prendre en compte tous les cas se révèle complexe comme le montre votre tutorial finalement (16 paragraphes quand même).
    Au moins avec le XML il y a les DTD ou les XSD qui permettent de vérifier l'intégrité du fichier avant la lecture.
    C'est mitigé...
    La validation XSD est très coûteuse et bien souvent, elle ne permettra pas de se passer d'une validation métier "a mano". Et lire un gros fichier XML (de l'ordre des 500mo-1GB) est infiniment plus complexe que lire un gros fichier CSV.

    Toutes les applications proposent des export CSV mais jamais sous la même forme (séparateur duifférents, pas de protections, ...) et au final c'est pénible à intégrer. Combien d'imports plantent en plein milieu parce que notre parseur de fichier CSV ne prend pas tout en charge?
    Je suis moyennement d'accord. CSV souffre de l'absence de spécification claire mais il est admis que les tokens sont séparés par des virgules, peuvent ou non être entourés de guillemets et qu'un dédoublement de guillemets sert d'échappement.
    Si vous intégrez ces règles, votre parseur peut facilement gérer 98% des sorties générées par d'autres produits.

  7. #7
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Attention aux fermetures des ressources. Si tu fermes le FileReader en espérant qu'il va automatiquement fermer le BufferedReader, que va-t-il se passer si ça plante ?... cf. bonnes pratiques de developpez... En outre, les codes de l'article sont volontairement tronckés pour des raisons de lisibilité. Vous avez sans doute remarqué l'absence de try-catch...

    Pour le while, très bonne remarque.

    Le format CSV est définie par la RFC 4180. Toutefois on constate souvent des extensions communément admises. Il faut penser que les lecteurs CSV sont souvent écrits spécifiquement pour un format donné, de manière optimisée. Dans l'article, je m'amuse à deviner le format utilisé mais c'est juste un jeu. En vrai le format est connu d'avance.

    Dans l'article, je fais l'impasse sur plusieurs points. D'abord l'encoding mais c'est une blague. Ensuite les data multilignes avec détection des délimiteurs mélangés. Et surtout les fichiers volumineux.

    J'avais pensé faire un chapitre sur les accès concurrents, puisque j'utilise les CSV comme une base de données, mais en vrai ils doivent être utilisés pour de la transmission de données, et donc il n'y a pas de vrai sujet de concurrence ou de mise-à-jour.

    Quand à la validation, qu'en dire. Ca dépend un peu de l’émetteur du flux. En général, je zappe carrément la phase de validation. C'est trop couteux. Si ça se passe mal, je lance un roll back.

  8. #8
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 725
    Points : 6 918
    Points
    6 918

    Par défaut

    Citation Envoyé par thierryler Voir le message
    Attention aux fermetures des ressources. Si tu fermes le FileReader en espérant qu'il va automatiquement fermer le BufferedReader, que va-t-il se passer si ça plante ?... cf. bonnes pratiques de developpez...
    Lol c'est le contraire. Vous laissez le BufferedReader fermer le FileReader. Le BufferedReader possède une instance de FileReader, pas l'inverse.

  9. #9
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Jeu oui pardon, je voulais dire l'inverse. Bref si tu le laisses faire, et que ça se passe mal, tu risque d'avoir des ressources non fermées, voire pire mal fermées. Il y a d'ailleurs des implémentations de la jvm qui ne sont pas très propres la dessus. Je crois qu'on en a beaucoup parlé à l'arrivée de java 7.

  10. #10
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 725
    Points : 6 918
    Points
    6 918

    Par défaut

    Citation Envoyé par thierryler Voir le message
    Bref si tu le laisses faire, et que ça se passe mal, tu risque d'avoir des ressources non fermées, voire pire mal fermées. Il y a d'ailleurs des implémentations de la jvm qui ne sont pas très propres la dessus. Je crois qu'on en a beaucoup parlé à l'arrivée de java 7.
    Non en fait je ne suis pas tout à fait d'accord et je maintiens que seul le wrapper positionné au plus haut a besoin d'être explicitement fermé. Conformément à la spécification (voir doc de l'interface Stream et Reader) c'est de sa responsabilité d'appeler la méthode close() de l'objet qu'il encapsule. En gros vous devriez juste fermer bufferedReader dans cet exemple.

    S'il échoue en appelant la méthode close() du FileReader, vous n'aurez pas plus de chance que lui. Par ailleurs une exception à la fermeture d'une ressource est quasi-systématiquement lié à une exception précédente (style une exception se déclenche dans votre code de lecture/écriture et la ressource devient instable, puis votre finally appelle courageusement close() qui échoue à son tour, cette deuxième erreur est ingérable et sauf cas extrême on la supprime afin qu'elle n'occulte pas la première).

  11. #11
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Oui et non. Même si je ne suis pas complétement d'accord avec cette interprétation de la théorie, il ne faut pas oublier qu'en pratique, on est loin du compte, surtout avec des objets maison et/ou des jdk custom...

    Dans tous les cas, ça ne mange pas de pain de fermer la ressource soit même quand on n'en a plus besoin.

    Le bon pattern serait quelque chose du style :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
    Resource resource = null;
    try {
      resource = open();
     
      foo();
      return valeur;
    } catch (Exception e) {
      log.error()
    } finaly {
      if(resource != null) {
        try {
          resource.close();
        } catch(Exception e) {
          exit-machin-truc()
        }
      }
    }
    Vive Java 7 ;-)

    Quoi que les ressources ne sont pas toutes logées à la même enseigne dans java 7 :-( Et c'est précisément pour une bonne raison. Devinez laquelle...

  12. #12
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 725
    Points : 6 918
    Points
    6 918

    Par défaut

    Citation Envoyé par thierryler Voir le message
    Oui et non. Même si je ne suis pas complétement d'accord avec cette interprétation de la théorie, il ne faut pas oublier qu'en pratique, on est loin du compte, surtout avec des objets maison et/ou des jdk custom...

    Dans tous les cas, ça ne mange pas de pain de fermer la ressource soit même quand on n'en a plus besoin.
    Mais j'ai jamais dit qu'il ne fallait pas fermer la ressource soi-même.
    Je me demande si depuis le début on ne parle pas chacun d'une chose différente.

    J'attire juste ton attention sur le fait que lorsque tu appelles la méthode close() du bufferedReader, celle ci appelle la méthode close() du FileStream par convention. Et que par conséquent ton appel explicite à FileStream.close() a la suite a au mieux aucun effet, au pire génère une erreur car l'état de la ressource est déjà fermé.

    C'est tout! Je pense qu'il y a un malentendu car tu dis que tu n'es pas d'accord avec moi et ton exemple fait exactement ce que je dis (si ce n'est la ligne "exit-machin-truc()" que je supprimerai ). D'ailleurs si tu regardes le pattern "using" de C#, il fait exactement ce que je dis, en cas d'erreur tenter la fermeture et ignorer silencieusement l'éventuelle exception que cette dernière opération provoquerait afin qu'elle n'occulte pas l'erreur initiale, et je suis presque prêt à mettre ma main à couper que le "try" de java 7 fait grosso-modo la même chose.

  13. #13
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Citation Envoyé par _skip Voir le message
    J'attire juste ton attention sur le fait que lorsque tu appelles la méthode close() du bufferedReader, celle ci appelle la méthode close() du FileStream par convention. Et que par conséquent ton appel explicite à FileStream.close() a la suite a au mieux aucun effet, au pire génère une erreur car l'état de la ressource est déjà fermé.
    J'ai bien compris ce que tu veux dire. Tu veux fermer uniquement le BufferedReader en pensant que ça fermera aussi le FileReader. C'est légitime car la javadoc dit :

    Closes the stream and releases any system resources associated with it.
    Mais j'ajoute que certaines JVM sont connues pour ne pas bien le faire (disons bug parfois dessus). Je crois même (corrigez-moi si je me trompe) qu'il y a un épisode du cast-codeur qui en parle.

    En outre, pourquoi je dis ça ? C'est à cause du genre de code bien vache qui suit, et que j'ai déjà rencontré de manière plus complexe mais qui revenait au même dans certaines conditions :

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
    public class MonBufferedReader extends BufferedReader {
     
    	public MonBufferedReader(Reader arg0) {
    		super(arg0);
    	}
     
    	@Override
    	public void close() throws IOException {
    		System.out.println("Je suis un vilain reader !");
    		System.out.println("Je fais des choses pas cool...");
    		throw new UnsupportedOperationException("snif snif");
    	}
     
    }
    EDIT : Petit bonus de Xeb http://blog.xebia.fr/2011/07/06/gest...ille-le-clerc/ Dans cette vidéo, Cyrille explique un peu tout ce qu'on a dit. Il précise que quand on décompile certains drivers (en parlant de jdbc) on a des grosses surprises et que ça ne respecte pas la doc.

  14. #14
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 725
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 725
    Points : 6 918
    Points
    6 918

    Par défaut

    Citation Envoyé par thierryler Voir le message
    Mais j'ajoute que certaines JVM sont connues pour ne pas bien le faire (disons bug parfois dessus). Je crois même (corrigez-moi si je me trompe) qu'il y a un épisode du cast-codeur qui en parle.
    Je serai curieux de savoir lesquelles... Ca m'étonne car la validation d'une JVM compatible java est plutôt strict et je ne crois pas personnellement que ça passerait la test suite. Pour ton exemple, c'est une faute du développeur et elle est plutôt grave, trop à mon goût pour que j'utilise son code dans un projet professionnel.
    Si tu dois remettre systématiquement en question le bon fonctionnement des interfaces, c'est la paranoïa car tu ne peux plus te fier à rien.

  15. #15
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Alors je propose d'en rester là sur le point du "close". J'ai ouvert un autre fil pour continuer la discussion : http://www.developpez.net/forums/d11...e/#post6251634
    Après tout ce fil ci concerne l'article sur les fichier CSV et on est en train de diverger.

    Juste pour conclure, disons qu'il y a de la matière à discuter et que, dans tous les cas, le double "close" ne peut pas faire de mal. Au pire ça râle un peu, au mieux ça sauve des nuits.

  16. #16
    Membre Expert
    Homme Profil pro Nicolas Saumande
    Architecte Décisionnel
    Inscrit en
    février 2008
    Messages
    767
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Saumande
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte Décisionnel

    Informations forums :
    Inscription : février 2008
    Messages : 767
    Points : 1 013
    Points
    1 013

    Par défaut

    Bonjour,

    Une petite question naïve, dont vous ne me tiendrez pas rigueur (merci par avance).

    Quel serait l'intérêt de gérer la lecture de fichiers cvs via le code java que vous proposez, alors qu'il existe des outils ETL du genre Talend Open Studio qui le font très bien (et du coup faisable par les néophytes comme moi qui ne connaissent pas, ou peu, le language java)?

    Merci,
    Nicolas

  17. #17
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Très bonne question au contraire. J'en parle un peu dans l'article mais j'aurais pu insister un peu plus.

    L'idée, déjà, c'est d'avoir une lib utilisable dans le programme qu'on est en train d'écrire. Ensuite, il existe des lib déjà toute faites, comme open-csv, qui font ce travail très bien. L'idée de l'article, ce n'est pas de savoir écrire une Nième lib sur le sujet, mais de comprendre les problèmes posés par la lecture CSV. D'ailleurs l'article fait (volontairement) l'impasse sur plusieurs points. Il y a un ensemble de compétences basiques à connaitre, et un ensemble de problématiques à prendre en compte.

    De manière générale, on peut être utilisateur d'un ETL sans jamais savoir ce qui se passe dedans. Par analogie, je n'ai aucune idée de ce qui peut se passer dans le moteur de ma voiture quand j'appuie sur la pédale d’accélération ou de frein. J'ai bien une vague idée mais alors vraiment vague. Mais je ne suis pas mécanicien. Par contre je suis développeur, donc à un moment ou un autre, il va falloir que je sache de quoi il retourne vraiment dans les programmes que j'utilise, surtout si je dois les recommander à un client.

  18. #18
    Membre Expert
    Homme Profil pro Nicolas Saumande
    Architecte Décisionnel
    Inscrit en
    février 2008
    Messages
    767
    Détails du profil
    Informations personnelles :
    Nom : Homme Nicolas Saumande
    Âge : 39
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte Décisionnel

    Informations forums :
    Inscription : février 2008
    Messages : 767
    Points : 1 013
    Points
    1 013

    Par défaut

    Ok, je vois.
    L'idée de l'article est de réfléchir à la problématique et non de proposer des solutions.

    Le fait que certains commentaires abordent les soucis rencontrés m'avait laissé un peu perplexe. De même que le fait que les limitations que vous citez sur les volumétries qui peuvent être traitées sont bien en dessous de ce que peuvent faire les ETL.

    En tout cas, merci d'avoir pris le temps de me répondre.
    Nicolas

  19. #19
    Rédacteur
    Avatar de thierryler
    Homme Profil pro Thierry Leriche-Dessirier
    Inscrit en
    octobre 2007
    Messages
    3 578
    Détails du profil
    Informations personnelles :
    Nom : Homme Thierry Leriche-Dessirier
    Localisation : France

    Informations forums :
    Inscription : octobre 2007
    Messages : 3 578
    Points : 10 054
    Points
    10 054

    Par défaut

    Disons qu'en partant uniquement de cet article, ce n'est pas possible d'écrire un ETL ; il faut connaitre beaucoup d'autres choses. Par contre, je prend le cas de mes étudiants, à partir de cet article, ils vont apprendre plein de trucs. Et ils seront capables de faire des traitements rapides sur des fichiers pas trop complexes.

    On a vu que, déjà, sur la fermeture des ressources, il y a plein de choses à savoir.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •