in reply to Help Sorting a CSV File

If you're doing a lot of CSV stuff you probably want to look at DBD::CSV.
use DBI; use 5.014; use warnings; # See "Creating database handle" below my $dbh = DBI->connect ("dbi:CSV:", undef, undef, { f_ext => ".csv/r", RaiseError => 1, }) or die "Cannot connect: $DBI::errstr"; my $sth=$dbh->prepare("select * from data order by SUPPLIER_CODE;"); $sth->execute(); local $"=q{,}; while (my $values_aref=$sth->fetchrow_arrayref ) { #warn Data::Dumper->Dump([\$values_aref],[qw(*values)]),' '; print "@$values_aref\n"; };

Replies are listed 'Best First'.
Re^2: Help Sorting a CSV File
by Tanktalus (Canon) on Oct 06, 2019 at 23:42 UTC

    THIS. If you have data, treat it as data. It's a bit more work to set up the first time, but after that it's so much easier - switching from csv to sqlite to mysql to Db2 to ... doesn't matter, it's so much easier once you see your data as actual data rather than a file format to fight with.

    Life has taken me far afield from Perl (mostly C# and Javascript nowadays), but there's so much I've learned in perl that is relatively straight forward in other languages. Except this one: treating a csv file as a source for SQL without having to import it into an actual database system. There's lots I miss about perl, and many things in other languages that are the same (with a different, usually longer, syntax), but this one tops my list. You're using perl, take advantage of it.

      I agree.

      However, there is a another step in-between text and database, in the form of a "Foreign Data Wrapper", to let the database serve up the underlying (csv-)textfile:

      psql -qX << SQL_TXT create server if not exists temp_fs foreign data wrapper file_fdw; drop foreign table if exists ft_pm2 cascade; create foreign table ft_pm2 ( "CAT_HEADER" text , "SUPPLIER_CODE" text , "CUSTOMER_CODE" text , "F4" text , "F5" text , "F6" text , "F7" text , "F8" numeric ) server temp_fs options ( format 'csv' , header 'true' , filename '/tmp/data.txt' ); copy(select * from ft_pm2 order by 2, 3) to stdout with (format csv, h +eader true); SQL_TXT

      Results are (again):

      CAT_HEADER,SUPPLIER_CODE,CUSTOMER_CODE,F4,F5,F6,F7,F8 CAT_LINE,0001P,ABC12345,20190924,,1,Z,3.36 CAT_LINE,0001P,ABC23456,20190924,,1,Z,2.14 CAT_LINE,0001P,ABC34567,20190924,,1,Z,12.23 CAT_LINE,0002P,ABC12345,20190924,,1,Z,4.26 CAT_LINE,0002P,ABC23456,20190924,,1,Z,1.21 CAT_LINE,0002P,ABC34567,20190924,,1,Z,22.24

      Such SQL using a 'Foreign Table' reads the underlying csv/text file(s). The annoying part is setting up the table , for instance in the case of tables with hundreds of columns you need a separate little application to do that, and this is where perl comes in handy (reading the header line and turning it into the CREATE TABLE column-list).

      Weaknesses and strengths:

      Advantages: SQL access to csv data. DBD::CSV delivers SQL as in SQL::Statement::Syntax which is nice but basic. The Data Wrapper's Foreign Table gives you access to the data via the full postgres SQL engine: Window Functions, Grouping Sets/Cube/Rollup, Generated Columns, Partitioning , etc., etc.)

      Disadvantages: Needs Postgres, and with extension file_fdw installed. Table remains read-only. No indexing possible, so that huge csv-files can make it slow (alhough 'copying' onto a materialized view [3] on the foreign table makes of course indexing possible again). Filesystem access for the postgres superuser is necessary.

      It all depends what you want to do.

      [1] file_fdw - this foreign data wrapper reads text files

      [2] Create Server

      [3] Create Foreign Table

      [4] Create Materialized View