textql VS cq

I like textql [0] better for this use case, as it's simpler in my mind.

[0] https://github.com/dinedal/textql

Primarily, you are right. SQL is for working with structured data and that largely covers RDBs. However, there are tools (like textql) that allow you to query CSV files and the effort works with most other text files that have some kind of structure.

As the author of textql ( https://github.com/dinedal/textql ) - thanks for the shoutout!

Looks great, I love more options in the space for CLI based data analysis tools! Fantastic work!

Apparently, there were many who thought the same thing; Tools to execute SQL against CSV were trdsql, q, csvq, TextQL. They were highly functional, hoewver, had many options and no input completion. I found it just a little difficult to use.

Reminds me of the textQL extension that's available in Asciidoc.

Point it to an external CSV file, enable TextQL, and bam, there's your query returned as a table. Handy for parts lists, inventory, that kind of crap.

https://github.com/dinedal/textql

https://gist.github.com/mojavelinux/8856117

Through more magic, you COULD of course use stuff like Spark, or easier with programs like TextQL, sq, OctoSQL.

Somewhat-kinda related, the textql extension for Asciidoctor is so dang useful it should be in core.

https://gist.github.com/mojavelinux/8856117

I use this as a "centralized parts repository" for big ol' maintenance manuals. Refresh from PDM/PLM/LSA/Whatever. Rebuild for new parts data.

Built on TextQL, natch

https://github.com/dinedal/textql

It seems beneficial for my case.

I have a light wrapper around SQLite called cq[1], to make querying CSVs with SQL more convenient. The point of the tool is to facilitate making ad-hoc, one-off queries on CSV data. CSVs don't specify the types of their columns, and they're either text or numeric. Having to be explicit on what the columns are would be a downside for me. Many CSVs have a ton of columns and I often care only about a few columns for one particular query I'll write and run once and never again.

I've fallen into the trap[2] where imported columns compare alphabetically despite them being numbers. I've been casting in my queries and was considering adding argument syntax for specifying the types of certain columns, but now that I see this, I think the behavior on specifying everything as NUMERIC is more desirable. It's more like Excel/LibreOfficeCalc, where you can just use numbers and they behave like numbers without having to be super-explicit.

I do very much agree that it's not desirable design for the DB of an app. There type-safety is more desirable.

[1] https://github.com/jolmg/cq

[2] https://news.ycombinator.com/item?id=28071615