Re: [9fans] Interested in improving networking in Plan 9

[Anthony Sorace <anothy@gmail.com>]

i've not used matt's sql module itself (i should check it out) so i
can't comment on his implementation, but... SQL is really ugly. it's
not hard to construct something that provides the same functionality
in a much more palatable form. aesthetics aside, if you're dealing
with a database-heavy app, it can make the code much easier to read.

somewhat harder is creating such a module in a way that's not specific
to a specific database, or even sql. this is similar (in theory) to
what the various php database modules do. this can be important if
your application is delivered/deployed in an environment where you
don't have control over what database is being used (although if the
database is important for your app, i think not having control over
the database is a poor position to be in).

not any harder but a lot less general is the option of wrapping the
database around a higher-level abstraction. you can do things like
data constraints and validations in the application code, rather than
in the sql database itself, which always feels like this random
bolt-on to the application logic. in the last large database-centered
project i was involved in, owing in large part to the lead
programmer's linguistics background, we called this the ontology
layer: it defined the things that exist. the rest of the app only had
to deal with what was in there, and it took care of mapping things to
a backing store.

at the layer of ontology, a fs-like interface can work pretty well.
i'm less convinced it's worth doing much with a lower-level database
beyond a slightly smart data channel.