Re: [TUHS] cut, paste, join, etc.

[Grant Taylor via TUHS <tuhs@minnie.tuhs.org>]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On 2/16/21 7:26 PM, Will Senn wrote:
> Oops. That's right, no username & password, but you still need to bring 
> it up and interact with it... accept, as you say, you can enter your sql 
> as an argument to the executable. OK, I suppose ... grump, grump...

;-)

Take a moment and grump.  I know that I've made similar mistakes from 
unknown options.

> Not quite what I was thinking, but I'd be hard pressed to argue the 
> difference between creating a handful of files in the filesystem 
> (vs tables in sqlite) and then using some unix filter utilities to 
> access and combine the file relations (vs passing sql to sqlite)

I don't know where the line is to transition from stock text files and 
an actual DB.  I naively suspect that by the time you need an index, you 
should have transitioned to a DB.

> other than, it'd be fun if there were select, col, row (grep?), join 
> (inner, outer, natural), utils that worked with text without the need 
> to worry about the finickiness of the database

I'm confident that it's quite possible to do similar types of, if not 
actually the same, operation with traditional Unix utilities vs SQL, at 
least for relatively simple queries.

The last time I looked, join didn't want to work on more than two inputs 
at one time.  So you're left with something like two different joins, 
one of which working on the output from the other one.

I suspect that one of the differences is where the data lives.  If it's 
STDIO, then traditional Unix utilities are king.  If it's something 
application specific and only accessed by said application, then a DB is 
probably a better bet.

Then there's the fact that some consider file systems to be a big DB 
that is mounted.  }:-)

> (don't stone me as a database unbeliever, I've used plenty in my day).

Use of something does not implicitly make you a supporter of or advocate 
for something.  ;-)

I like SQLite and Berkeley DB in that they don't require a full RDBMS 
running.  Instead, an application can load what it needs and access the 
DB itself.

I don't remember how many files SQLite uses to store a DB.  A single (or 
few) file(s) make it relatively easy to exchange DBs with people.  E.g. 
someone can populate the DB and then send copies of it to coworkers for 
their distributed use.  Something that's harder to do with a typical RDBMS.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]