Re: [9front] SQL

[Kurt H Maier <khm@sciops.net>]

On Sun, Jan 10, 2021 at 07:20:27PM -0800, William Gunnells wrote:
> Okay so plan9 does not have DB because...well it's a file based
> system. Okay okay so how would you manage large data. grep would suck.
> I guess sqlite would work but is that even ported. I read somewhere
> about using: https://github.com/harelba/q/ I don't know about that. I
> don't have a practical use as of yet. Just curious. It seems like a
> challenge to build some sort of http server in plan9 with basic
> webauth capability and store data in a file. What's the file size
> limitation? 9front has a list server. I'm sure that data is pretty
> extensive but those pages are not being served. Thoughts?

Plan 9 has databases.  One example is ndb.  Another is kenji's desktop
search system, kirara.  

Your question conflates the concept of a database with the access
mechanism.  SQL is a query language.  The reason it's not got much
traction on Plan 9 is that most SQL engines are closely tuned to their
host environment in order to stanch the bleeding on the traumatic
performance hit taken when you wind up using a data access language that
doesn't map well to the actual storage primitives your operating system
provides.

ndb declares relationships in terms of tuples, which are just
collections of key-value pairs.  Kirara works more like an indexing
system that stores points from a given string to the file that contains
it.  Neither of these approaches require the massive amount of effort
that would be required to write a performant SQL engine that doesn't
corrupt your data along the way.

On Plan 9, people tend to think about what data they're trying to
access, and create data structures that make it easy to do the task your
program is trying to accomplish.  

I don't know why you think making a web server would be such a
challenge, since eekee has provided a pretty good one written in shell
script (rc-httpd).  It includes HTTP Basic Auth, but works just as well
without it (for example, werc can handle its own user authentication).

I suppose the inevitable question is "what exactly are you trying to
accomplish?"  If the answer is "I'm not sure yet," then SQL in front of
a relational database might seem like a good idea.  But there's nothing
innate about tables and rows that can't be done with regular files and
indexes and shit.  In fact, that's what the RDBMSes are doing behind the
scenes anyway, unless they're backed by object storage, in which case
they've delegated to the object store.  At some point, on systems like
Unix and Plan 9, you have to open/read/write/close just like everyone
else.  You just have to decide how tall you want to build your
sandcastle of abstractions in the process.

khM