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