Some time back, I blogged about this - developed further.
I really like SQL, and I really like the Unix userland. Neither are perfect, but they are excellent tools. The barriers between them are too high, and I've been working on ways to lower that every so often.
Unix strength: architected as if always exist in design decisions strand of thought: Can we make this a stream of bits sensibly? Answer: not always yes - pragmatic with a preference. Stream of bits model: generally great for gluing software together, power.
SQL strength: captures relational model for data well, particularly with relational calculus. Concurrency, transactionality also plusses, but exposed power of queries most important.
Issue: existing SQL tools: great for exploring a database (generally - mysql and oracle have tools that are bad for different reasons). These are less useful for CL use. Programming APIs to database provide tools to get information in more structured ways - the kind of data one can export to the shell is not good enough. How can we do better?
First draft (previously described):
- dbgrep - pretends database is a directory hierarchy, treats second argument as a pseudopath, will search database for named string
- Evaluation: a nice tool, but very limited. Read-only, clumsy, no real query power, single-purpose
Idea for third draft: incorprate the second draft under another virtual directory, but add a query directory whereby people make subdirectories, drop a SQL query of arbitrary complexity into a textfile, and a data directory is made with a full table as well as per-tuple file exports. For the content from the second draft, allow users to update the tuple files to change the data in the database, deleting, altering, possibly renaming, etc.