Journal Le million pour Calc

Posté par  .
Étiquettes :
14
24
fév.
2010
L'un des développeurs d'OpenOffice.org, Kohei Yoshida, signale sur son blog qu'il a intégré dans Go-OO une série de modifications permettant de s'affranchir de la limite actuelle de 65536 lignes du tableur libre. Avec ses modifications, le tableur est plus réactif sur les documents existants et permet d'utiliser des feuillets contenant 1 millions de ligne (1 048 576 exactement).

Le développeur signale qu'il a réussi à faire ce tour de forces en tentant de ne pas dégrader l'utilisation de Calc dans la plupart des cas. Ce n'est pas l'avis de deux des développeurs employés par Oracle, qui estiment qu'il n'est pas encore temps d'intégrer cette modification. Ils ont noté que le calcul en chaine des cellules contenant des formules n'est pas assez optimisé pour tenir la charge. Ils ont également constaté que l'affichage des objets graphiques ou des notes est décalé. C'est un problème déjà connu sur la version actuelle, mais l'augmentation de la limite montre ce problème de façon trop flagrante.

Il est clair que ces problèmes seront résolus un jour ou l'autre dans la suite bureautique libre. En attendant, il a décidé de l'intégrer dans la version stable de Go-00 en version 3.2. Il est donc possible depuis une Ubuntu Lucid Lynx ou dans la prochaine version d'openSuse d'utiliser un tableau affranchie de la limite de 65536 lignes.

  • # Argl... un tableur n'est pas une base de données !

    Posté par  (Mastodon) . Évalué à 4.

    Même si cette nouvelle ne peut qu'être une bonne nouvelle, j'aimerais bien savoir qui peut utiliser plus de 64k lignes sur un tableur.

    65000 entrées, ça s'appelle définitivement une base de données.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 7.

      Ca m'a gêné plus d'une fois, notamment en important les données d'un TCPDUMP qui faisait dans les 200 000 lignes, il fallait le couper en plusieurs, faire des calculs dans les différentes feuilles et les totaux dans une nième.

      Ce n'est qu'un exemple. Et il y avait d'autres moyen de le gérer, mais ça va me servir, c'est sûr !

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  (Mastodon) . Évalué à 10.

        re-argl... : un TCPDUMP tu le traites avec un tableur ?

        Sérieusement, apprends awk, tu verras, ce sera du bonheur pour toi à l'avenir ! Fais l'effort pour les 3 ou 4 prochaines fois, ensuite tu gagneras un temps de dingue.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 9.

      Personnellement (et je ne pense pas être le seul), j'utilise très fréquemment Calc comme grapheur (comme GNUplot ou MatPlotlib mais en plus interactif pour la mise en forme). Ça permet aussi de rapidement faire des calculs sur des valeurs mesurées.
      Et puis, un copier/coller et on a la courbe dans un document texte.
      Ces valeurs mesurées proviennent bien souvent de fichiers .csv générés par divers outils, scripts, oscilloscope numérique... et ces fichiers dépassent très facilement les 65000 lignes.

      Alors, si vous avez quelque chose de simple à me proposer pour avoir une courbe en ~30 secondes à partir d'un fichier texte ou .csv, je suis preneur.

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  (Mastodon) . Évalué à 1.

        Je ne connais pas ce domaine, mais justement GNU Plot ne sert pas à ça ?

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  . Évalué à 5.

        Alors, si vous avez quelque chose de simple à me proposer pour avoir une courbe en ~30 secondes à partir d'un fichier texte ou .csv, je suis preneur.

        Matlab (çapuecépalibre), ou Octave ( http://www.gnu.org/software/octave/ ).

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  . Évalué à 8.

        R - http://cran.r-project.org/

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  . Évalué à 4.

        A te proposer :
        lancer octave,

        Mon_fichier.txt est formate en ligne pour le temps et colonnes pour les variables cet exemple traite un fichier de 3 colonnes et n lignes

        load("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier";print -deps "Graphe_de_Mon_fichier.eps"

        dans scicoslab

        M=fscanfMat(("Mon_fichier.txt");plot(Mon_fichier(:,1),Mon_fichier(:,2),Mon_fichier(:,1),Mon_fichier(:,3));title "graphe de Mon_fichier"

        Tu peux aussi le faire très facilement avec matplotlib, mais je ne suis pas aussi à l'aise.

        Je pense que cela prend moins de 30 secondes, en tout cas nettement moins que de faire l'import dans calc, sélectionner les colonnes, demander un nuage de points, ...., cliquer pour enregistrer le fichier !


        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 1.

          Tu peux aussi le faire très facilement avec matplotlib, mais je ne suis pas aussi à l'aise.

          pour plotter x=colonne1, y=colonne2, ça fait un truc du genre:
          from pylab import *
          a = open("data.csv").read().split('\n')
          plot(a[0],a[1],title="joli",color="pink",xlabel="oh",ylabel="ah")

          • [^] # Re: Argl... un tableur n'est pas une base de données !

            Posté par  . Évalué à 3.

            Hum non, dans ton exemple a[0] et a[1] seront les première et 2eme lignes du fichier.
            J'utiliserais plutôt
            from pylab import *
            a = loadtxt('data.csv')
            plot(a[:,0]),a[:,1])

            Et je suis aussi d'avis que le temps d'écrire ça, openoffice calc n'aurait peut-être pas encore fini de démarrer :D (pas taper ! - oui bon ok on serait certainement déjà arrivé à la boite de dialogue d'ouverture du fichier csv)
            (surtout si on utilise ipython -pylab, ce qui évite l'import de la première ligne)

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  (site web personnel) . Évalué à 1.

        Je ne sais pas si ca te parait assez simple mais :
        gnuplot -p -e "set datafile separator ','; plot '-' using 1:2" < test.csv

        (en adaptant using 1:2 au colonnes que tu souhaites utiliser)

        Pour en faire un fichier image :
        gnuplot -p -e "set datafile separator ','; set term png; set output 'test.png'; plot '-' using 1:2" < test.csv

        Après forcément ça demande un petit effort pour adapter la forme à tes besoins.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  (site web personnel) . Évalué à 4.

      Bien d'accord avec toi et pourtant dans le milieu professionnel, beaucoup de tableur sont utilisés ainsi :/

      Et sans parler des problèmes d'accès concurrents au dit tableur.
      On m'a même demandé de poser des droits sur une ligne de cellule selon la personne qui ouvre le fichier :D

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 8.

      J'utilise souvent un tableur pour faire des constats rapides sur des données - en l'occurrence, des logs de communications téléphoniques. Pourquoi pas prendre une base de données ?
      Parce que :
      -En sélectionnant quelques valeurs à la souris, j'ai tout de suite leur moyenne, somme, etc...
      -Je filtre les résultats en 30 s (oui, je pourrais taper des requêtes SQL à la place, mais c'est plus long, bien plus long!)
      -Le déplacement dans les données est très rapide
      -Ajouter ou supprimer une colonne prend 3 secondes
      -Faire le même calcul sur toutes les lignes est ultra rapide, on peut conserver le résultat...
      -On peut colorer certains résultats, ajouter des commentaires, etc..

      T'aurais un outil mieux à proposer pour faire tout ça ?

      Je suis d'accord avec toi, un tableur n'est pas une base de données, mais c'est un super outil pour trier et mater les données tabulaires. Et une base SQL c'est à chier pour faire ce genre de boulot.

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  . Évalué à -1.

        Ce dont tu as besoin, c'est d'un bon outil de reporting. Je connais principalement Business Object (pas libre, mais très puissant). En libre, tu en as une palanquée, dont iReports (basé sur jasperreports) qui est pas mal.
        Une fois qu'on a pris la peine d'apprendre le paradigme de ces logiciels, c'est très très rapide.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 10.


      Même si cette nouvelle ne peut qu'être une bonne nouvelle, j'aimerais bien savoir qui peut utiliser plus de 64k lignes sur un tableur.

      65000 entrées, ça s'appelle définitivement une base de données.


      Tout à fait, et 640 ko sur un ordinateur personnel devrait suffire à tout le monde. ;)

      À mon avis, repousser les limites d'un outil est toujours une bonne idée. Et si tu veux considérer qu'une feuille calc avec 200 000 lignes est une base de données, tu peux : c'en est bien une. C'est bien une collection de données. Avec 20 lignes, c'est le cas aussi. Calc est bien un outil qui permet de manipuler des collections de données. Ces données ne s'interrogent pas en SQL, on est d'accord, mais ce n'est pas ce qui défini une base de données.

      Le choix du "bon" outil va dépendre du but. Si il faut pouvoir faire rapidement un graphique avec 500 000 nombres, calc entre dans la liste des possibilités, c'est toujours intéressant. Non ?

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 3.

      Bon, imagine que j'ai un calcul qui produit 200 000 données sous la forme : données en entrée/données en sortie. Pourquoi voudrais-tu que je passe par une base de données pour tester les résultats ? Une feuille de calcul est largement plus pratique.

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  (Mastodon) . Évalué à 5.

        Qu'est-ce que tu appelles "tester un résultat" ? Tu aurais un exemple concret ?

        Je ne suis pas du tout anti-tableur, je suis anti mauvaise utilisation des tableurs, et je suis persuadé que c'est bcp trop souvent le cas. Ensuite, je ne demande qu'à changer d'avis... C'est juste que au boulot je manipule souvent des fichiers csv de l'ordre de quelques centaines de lignes (seulement !), et que déjà sortir Excel m'énerve quand un grep suffit...

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 2.

          Bah, moi qui n'aime vraiment pas les tableurs en règle générale, il n'y a guère qu'avec beaucoup de données qu'il m'arrive d'en utiliser. Le cas typique : des données exportées en CSV par un programme de mesure (propriétaire, hein, pas question de régler le problème à ce niveau) qui écrite des tableaux sans logique apparente. L'intérêt du tableur c'est justement d'apporter une représentation visuelle de l'ensemble qui permet d'identifier rapidement les différents jeux de données présents, de réorganiser un peu le fichier et d'enregistrer le tout de manière à pouvoir traiter les informations avec un vrai programme adapté (Octave, Scilab, R, etc).

          Je me doute que cet usage n'est pas l'usage premier d'un tableur, mais s'il y répond, je ne vois pas de meilleur outils. C'est sûr qu'une feuille de compta à 1 000 000 de lignes je doute que ça serve (et encore, même pour la compta, il me semble qu'il a des outils bien plus adaptés qu'un tableur).

        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 9.

          je suis anti mauvaise utilisation des tableurs, et je suis persuadé que c'est bcp trop souvent le cas

          Je pense que ça vient du fait qu'il est facilement utilisable pour beaucoup d'utilisations différentes et que le temps perdu par une mauvaise utilisation du produit est inférieur au temps de formation à un outil adapté mais pas souvent utilisé.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 2.

          Excel <-> grep

          C'est vrai qu'entre utiliser grep ou redémarrer sous Windows pour utiliser Excel, le choix est vite fait.

        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 1.

          Exemple :
          Produit acheté|catégorie produit|coût unitaire|Taux de TVA|Quantité|Prix HT|Prix TTC

          Je veux :
          - tester que le taux de TVA est bien adapté à la catégorie produit
          - confirmer que prix HT = quantité * coût unitaire
          - confirmer que prix TTC est le bon suivant le taux de TVA

          Sous un tableur, c'est fait en deux minutes. Sur une base de données, je perdrais plus de temps à étudier comment faire, sans parler de la réalisation.

          • [^] # Re: Argl... un tableur n'est pas une base de données !

            Posté par  . Évalué à -7.

            > Sous un tableur, c'est fait en deux minutes. Sur une base de données, je perdrais plus de temps à étudier comment faire, sans parler de la réalisation.

            c'est une blague ?

            ca veut juste dire que tu sais un peu utiliser un tableur, enfin écrire une formule ou un filtre. youhou.

            et que tu ne sais pas utiliser une base de données ou un outil de reporting

            or ça peut être hyper-simple, surtout si on t'a préparé une vue à l'avance et que tu n'as plus qu'à lire un rapport ou surveiller des alertes, genre depuis une page web ou un client mail ou assimilé (RSS...)

            parce que ce genre de demandes c'est très répétitif et si tu fais plus de deux fois la même manip dans ton tableur en réinventant la roue à chaque fois... tu mérites juste une paire de claques.

            • [^] # Re: Argl... un tableur n'est pas une base de données !

              Posté par  . Évalué à 2.

              J'adore l'agressivité déplacée...
              C'est le genre de truc qu'on fait une fois, il faudrait vraiment être un abruti pour demander des outils de reporting alors que c'est fait en deux minutes sous Excel et que ça n'a pas vocation à être réutilisé.

              • [^] # Re: Argl... un tableur n'est pas une base de données !

                Posté par  . Évalué à -2.

                tu sais lire ?

                "si tu fais plus de deux fois la même manip"

                ou pas, on dirait

                si on te le demande une ou deux fois oui ça se fait à l'arrache. au delà, il faut commencer à se poser des questions. sauf quand on s'y refuse, évidement...

                • [^] # Re: Argl... un tableur n'est pas une base de données !

                  Posté par  . Évalué à 4.

                  Je sais lire :
                  > c'est une blague ?
                  Bel esprit de dérision sur mon cas que tu ne connais pas. Esprit borné, limité à sa propre expérience, avec à priori sur le reste du monde.

                  > ca veut juste dire que tu sais un peu utiliser un tableur, enfin écrire une formule ou un filtre. youhou.
                  Pas mal, je dis que faire un test rapide sous un tableur est plus rapide que jouer avec une base de données dans mon cas, et tu sous-entends que je sais à peine utiliser des fonctions basiques dans un tableur. Belle conception des autres et très belle compréhension de l'écrit dis-moi !

                  > et que tu ne sais pas utiliser une base de données ou un outil de reporting
                  Ca te viendrait pas à l'idée que ce n'est pas adapté à tout ? Que potentiellement, c'est un choix raisonné que je fais ?

                  > or ça peut être hyper-simple, surtout si on t'a préparé une vue à l'avance et que tu n'as plus qu'à lire un rapport ou surveiller des alertes, genre depuis une page web ou un client mail ou assimilé (RSS...)
                  J'ai jamais dit que ça ne pouvait pas être simple. Je dis juste que l'investissement initial peut ne pas valoir le coup.

                  > parce que ce genre de demandes c'est très répétitif et si tu fais plus de deux fois la même manip dans ton tableur en réinventant la roue à chaque fois... tu mérites juste une paire de claques.
                  Comment sais-tu que ma demande est répétitive, tu es devin ? Ensuite, ton "si tu" es réthorique et n'implique pas une vraie question de ton côté : tu considères forcément que je mérite une paire de claques.

                  Pas mal, m'accuser ensuite de ne pas savoir lire alors que tu as de tels aprioris, c'est impressionnant.

                  • [^] # Re: Argl... un tableur n'est pas une base de données !

                    Posté par  . Évalué à -4.

                    > Bel esprit de dérision sur mon cas que tu ne connais pas. Esprit borné, limité à sa propre expérience, avec à priori sur le reste du monde.

                    lol what ? tu ne connais pas mon cas donc en fait tu t'étales dans ce que tu me reproches, chapeau.

                    > Ensuite, ton "si tu" es réthorique

                    euh, non-non. retourne à l'école si (ah ah, si !) si tu as des soucis avec le mot "si" ou éventuellement songe à soigner une paranoïa naissante. je suis d'accord pour les réserves avancées et pour utiliser les moyens du bord avant d'avoir recours à la grosse artillerie, au passage.

                    > tu considères forcément que je mérite une paire de claques.

                    ah maintenant oui, c'est clair. et même plusieurs. mais je pense que ça ne suffira pas. encore bravo \o/

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 4.

      probablement des gens qui ont pas envie de s'emmerder avec du sql, a creer des tables, les modifier manuellement etc.

      Utiliser un sgbdr, meme simpliste genre access, pour y mettre une table avec 4 colonnes, comment dire...

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 0.

      Qui peut utiliser plus de 64k lignes sur un tableur ?

      Les gens qui veulent faire des calculs rapidement sans avoir à déployer tout un arsenal d'outils.
      Si le tableur fait le boulot aussi bien et plus rapidement, pourquoi s'en priver ?

      Pour des opérations complexes / répétitives (et automatisables) et /ou des données à partager entre plusieurs utilisateurs, là oui utiliser un tableur serait contre productif.
      Sinon, je ne vois pas le problème.

      Beaucoup d'utilisateurs en entreprise gèrent leurs données dans un tableur dans des cas ou il serait mieux d'utiliser une base SQL (ou autre).
      C'est une plaie d'avoir des données éparpillées comme ça, mais on ne peut pas non plus leur reprocher, vu leur niveau de connaissance technique.

      • [^] # Re: Argl... un tableur n'est pas une base de données !

        Posté par  . Évalué à 2.

        > on ne peut pas non plus leur reprocher, vu leur niveau de connaissance technique

        c'est comme laisser des gus promus mécanos ou chirurgiens opérer avec des outils totalement inadaptés au problème en face d'eux ?

        non merci.

        • [^] # Re: Argl... un tableur n'est pas une base de données !

          Posté par  . Évalué à 6.

          En l'occurence c'est ce que font les utilisateurs en entreprise.

          Maintenant si tu veux donner des cours de SQL a des types qui ne font pas la difference entre la barre des taches windows et les onglets de firefox, il va falloir te lever tres tot. Des comme ca, il y en a la pelle, quand tu pointes ton nez hors de la section informatique.

          Plutot que de leur payer 2 ans de cours d'infos, c'est plus rentable de leur filer un tableur.

          Bienvenue en dehors du monde des bisounours.

          • [^] # Re: Argl... un tableur n'est pas une base de données !

            Posté par  . Évalué à 3.

            > En l'occurence c'est ce que font les utilisateurs en entreprise.

            il y a toutes sortes d'utilisateurs dans toutes sortes d'entreprises ? oui, merci, je sais. il paraitrait même que le succès de certaines boites soient en partie relié au talent, enfin à la jugeotte, en informatique - bureautique incluse - de leurs utilisateurs.

            > Maintenant si tu veux donner des cours de SQL a des types qui ne font pas la difference entre la barre des taches windows et les onglets de firefox, il va falloir te lever tres tot

            je dis juste que ça va souvent être très inefficace, faute de bons outils ou d'un minimum de formation, qui seule donnera un peu d'expérience et la pratique, la jugeotte nécessaire pour faire ça efficacement. le voisin de bureau peut aider, maintenant ça sera pas toujours possible... surtout si ce sont deux technico-commerciaux qui se foutent sur la gueule.

            accessoirement tu peux faire des traitements sur des bases de données ou juste des fichiers à plat mais de très (très) gros volume et toujours avoir Excel en frontal, hein. et c'est transparent pour l'utilisateur. et ça fait plus de 10 ans que ça dure...

            > Des comme ca, il y en a la pelle, quand tu pointes ton nez hors de la section informatique.

            euh, et comment ils ont appris Excel ? parce que Word je comprends encore, on fait son CV avec, il y a des modèles, un gros bouton [G] pour foutre le texte en gras... c'est assez visuel

            Excel et des formules conditionnelles ou des filtres, non, ça tombe pas du ciel.

            > Plutot que de leur payer 2 ans de cours d'infos, c'est plus rentable de leur filer un tableur.

            ouais, s'ils se démerdent assez bien avec, que ça se résume en "pif-paf-pouf c'est torché". maintenant si ils sont perdus à chaque fois, oui et justement pour une question de rentabilité une petite formation peut s'imposer, sans même forcément parler de SQL ou d'autres diableries. ni même d'Access...

            > Bienvenue en dehors du monde des bisounours.

            *rires nerveux*

            bienvenue dans un monde d'inefficacité, tu voulais dire ? libre à chacun de se résigner face à la connerie et l'incompétence ambiante, mais si le bateau finit par couler, il faudra se demander si on n'a pas fait partie du problème plutot que de la solution. surtout si on t'avait confié la barre à un moment donné.

            • [^] # Re: Argl... un tableur n'est pas une base de données !

              Posté par  . Évalué à 4.

              Bienvenue dans le monde réel:

              - Une entreprise qui n'a pas grand chose à voir avec l'informatique, donc les utilisateurs ne se penchent que rarement sur l'Outil informatique le plus approprié à chaque tâche.

              - Tout le monde connaît un minimum excel, parce que c'est ce qu'on leur a appris à l'école/fac/autre

              - On t'envoie un fichier de 100 000 lignes de résultats, c'est les mesures faites sur des produits, on veut évaluer la fiabilité sur la prod en gros volume.

              - Tu peux t'auto-former à tous les produits que tu veux. Conséquence: tu vas te taper systématiquement tout le boulot tout seul pour sortir la moindre courbe, parce que tu auras un format de fichier que toi seul pourra lire.

              - Même si tu arrives à convaincre le reste de la boîte de te suivre dans ton logiciel plus mieux, tu dois envoyer les données et courbes au client, qui se fout complètement de ton super logiciel plus mieux et qui va te dire que "le fichier marche pas" (traduction: il fait des choses très bizarres quand on double clique, et quand on l'ouvre depuis excel, il nous insulte).
              Donc, tu devras quand même tout refaire sous excel...

              Conclusion: oui, il y a sûrement mieux, mais non, là tout de suite, je ne vais pas changer. Par contre, maintenant je peux utiliser OpenOffice et le faire utiliser à d'autres aussi. C'est pour moi une bonne nouvelle!

              • [^] # Re: Argl... un tableur n'est pas une base de données !

                Posté par  . Évalué à 2.

                > Tout le monde connaît un minimum excel, parce que c'est ce qu'on leur a appris à l'école/fac/autre

                tu exclues d'un coup les plus de 40 ans :)

                ensuite il faudra m'expliquer comment les gens faisaient avant (Excel) 2007 puisqu'on était limité à 64k lignes dans les versions précédentes

                • [^] # Re: Argl... un tableur n'est pas une base de données !

                  Posté par  . Évalué à 2.

                  J'en sais rien, je suis en R&D moi normalement, je bosse sur le problème de fiab en prod que depuis 2009!

                  Je soupçonne fortement une utilisation de origin auparavant, qui a dû tomber en désuétude.

                • [^] # Re: Argl... un tableur n'est pas une base de données !

                  Posté par  . Évalué à 2.

                  Ils coupaient les feuilles en 2 (deja vu faire)
                  C'est de la bricole evidemment, ca n'a pas la vocation d'etre quelque chose de serieux.
                  Mais pour faire quelques stats vite fait pour preparer une reunion ou faire un rapport, c'est suffisant.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  . Évalué à 3.

      Non, un ensemble de valeurs homogènes n’est pas une base de données, et comme tout le monde pense que base de données signifie SQL je rajouterai que c’est encore moins une base de donnée relationnelle. Faudra m’expliquer l’intérêt de SQL quand on a affaire à des ensembles homogènes de données sans relation entre elles, et qui seront lues de façon séquentielle.

      Si on veut traiter une grande quantité de données le mieux est de se mettre à un logiciel adapté. L’apprentissage n’est pas si long que ça. En attendant, pour gnuplot :
      plot "file.txt" using 1:2
      pour afficher la colonne 2 versus 1.
      Pour ceux qui connaissent Python je recommande fortement de se mettre à matplotlib et numpy, de même on fait (après les bon import) :
      a = loadtxt('file.txt')
      plot(a[:,0], a[:,1])
      Et on profite du langage pour faire absolument toutes les opérations et calculs voulus, très facilement.

      Sinon toute la palanquée de programmes spécialisés indiqués dans les différents commentaires, pour du calcul avancé. Pour du simple graphique, il y a kmplot et sûrement bien d’autres.

    • [^] # Re: Argl... un tableur n'est pas une base de données !

      Posté par  (Mastodon) . Évalué à 5.

      Bof tu sais moi j'ai connu une collègue qui nous a une fois sorti le plan d'un parking avec excel.

      Ça pourrait presque passer pour un comportement normal si je ne vous disais pas que le parking était constitué essentiellement de places de stationnement en épi et que le plan avait été réalisé avec des slashs/backslashs minutieusement alignés entre les différentes cellules. Elle était brune, je ne pense pas qu'une blonde aurait pu réaliser cette prouesse et elle aurait essayé avec word.

      Moi je dis respect.

  • # Pendant ce temps...

    Posté par  . Évalué à 3.

    ... je viens d'ouvrir une feuille de plus de deux millions de lignes avec Gnumeric.

    /me sifflote.

    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Pendant ce temps...

      Posté par  . Évalué à 1.

      Je me demande à quoi ça peut bien servir sans Pivot Tables (ou Tableau croisé dynamique dans la VF d'Excel) d'ouvrir 2 millions de lignes dans un "tableur".

      http://projects.gnome.org/gnumeric/faq.shtml#6

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Pendant ce temps...

        Posté par  . Évalué à 3.

        Ben vu que je ne sais pas ce qu'est un tableau croisé dynamique, je ne vois pas en quoi ça manque :-)

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Pendant ce temps...

        Posté par  . Évalué à 4.

        d'après les commentaires alentours, ils s'en servent pour analyser des logs au format texte ou CSV et vérifier des incohérences dedans ou faire de menus calculs puis filtres

        en gros, ce que grep ou awk ou perl ferait bien mieux et de façon totalement reproductible et automatisable. mais ça leur couterait leur boulot si ça venait à ce savoir :)

        • [^] # Re: Pendant ce temps...

          Posté par  . Évalué à 2.

          on peut aussi placer ces données en base de données (sqlite par exemple) et mettre en place quelques scripts sql agrémentés d'un autre language (php par exemple) pour réaliser la même chose pilotable à la souris.

        • [^] # Re: Pendant ce temps...

          Posté par  . Évalué à 1.

          en gros, ce que grep ou awk ou perl ferait bien mieux et de façon totalement reproductible et automatisable. mais ça leur couterait leur boulot si ça venait à ce savoir :)
          Merci pour la barre de rire, ca fait du bien au reveil, et celle la est tellement belle qu'elle va me faire la journee!!

          Bon, comme c'est ton idee et que t'as l'air super diplomate, c'est toi qui va t'occuper de la formation grep+awk de Jeanine secretaire de 45 ans qui panique deja a l'idee de passer d'excel 2003 a 2007.

          Mouarf.
          C'est pas possible d'etre aussi con serieux...

          • [^] # Re: Pendant ce temps...

            Posté par  . Évalué à 4.

            C'est pas possible d'etre aussi con serieux...

            Toi tu connais pas l'historique du monsieur...

            http://linuxfr.org/~Sufflope/23135.html
            http://linuxfr.org/~MrLapinot/23144.html

          • [^] # Re: Pendant ce temps...

            Posté par  . Évalué à 3.

            > formation de Jeanine, secretaire

            attends un peu, toto, t'as pas l'impression d'avoir manqué la moitié du flim ? ce n'est pas elle qui recevra le fameux fichier de 42 millions de lignes et qui devra chercher pourquoi le traitement N°G2LOQ merde en plein milieu.

            • [^] # Re: Pendant ce temps...

              Posté par  . Évalué à 2.

              Tiens, c'est marrant, t'appelles ca des ailes toi? Generalement les gens utilisent d'autres mots pour designer ca...

          • [^] # Re: Pendant ce temps...

            Posté par  . Évalué à 3.

            Votre commentaire aussi m’a bien fait rire. On parle de la limitation arbitraire (remarquez c’est toujours bon à prendre si elle augmente).

            Résumons donc : on a confié à Jeanine secrétaire de 45 ans un table de plus de 65k lignes de données. Hum… je doute que ça fasse partie du boulot d’une secrétaire, en tout cas sans vouloir les dénigrer j’aurai un peu peur pour mes données.

  • # Compatibilité ?

    Posté par  . Évalué à 3.

    Et ça fait quoi quand on ouvre une feuille de données de GoOO avec 500000 lignes dans OOo ?

    • [^] # Re: Compatibilité ?

      Posté par  . Évalué à 5.

      Un blougou a sens giratoire inverse.

    • [^] # Re: Compatibilité ?

      Posté par  . Évalué à 2.

      La même chose que quand tu ouvrira une feuille de données de 500 000 lignes de OOo 3.x (qui supporte 500k lignes) avec 3.2.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

  • # Alternatives pour grandes masses de données

    Posté par  . Évalué à 1.

    Au delà du débat adapté ou pas on a justement rencontré le problème de la limite des fichiers tableur récemment.

    Le cas d'utilisation : j'ai un large ensemble de données fournies par le client mais qui ont des problème de cohérence, d'encodage etc....
    Il faut donc que je dialogue avec le client pour lui montrer les données qui ne vont pas, qu'il corrige etc...
    Donc une feuille tableur ça semble le faire. Pb : trop de lignes.

    Dans les alternatives j'ai vu entre autre :
    - gnumeric
    - matrex http://matrex.sourceforge.net/
    - pyspread http://pyspread.sourceforge.net/

    Matrex semble le bon outil mais peut être pas simple de prise en main.

    Quelqu'un peut faire des retours sur ses outils ?

  • # Oracle

    Posté par  (site web personnel) . Évalué à 3.

    > l'avis de deux des développeurs employés par Oracle

    Instinctivement, je me suis dit "tiens, quel intérêt peut bien avoir Oracle à employer des devs sur OpenOffice ?". Et puis j'ai tilté. Pas bon signe, quand même.

    • [^] # Re: Oracle

      Posté par  . Évalué à 3.

      je crois que je m'y ferai jamais :(

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.