On db ↔ fs conversions: // datas (and their relations) MUST be kept consistents.
there's two things you could mean here: either the relations between the data fields/types or the relations between their values. SQL databases are interesting because they don't do anything to keep the relations consistent, at a schema level. there are some cases where this is valuable, but most of the time it just puts more of the burden on the application. enforcing consistency between values is a whole different matter. i don't think that belongs in the database layer of an application, but on the application side. why let the ap shove bad data at your DB? bad for scalability (if your DB is complex enough to need that kind of consistency checking, it's likely that it's a performance bottleneck alread), bad for security/stability (why let mallicious attackers fuzz your DB?), and largely needs to be done in the ap anyway (say your DB rejects a submission; are you just giong to panic, say "try again", or try and figure out what it didn't like?). // And MUST be updated frequently, in transaction. just curious: what is it about "transactionality" that you care about? atomicity, logging, roll-back (atomic roll-back)? // Application code cannot do that, since it's too subject to // modifications... i'm not convinced. you can simply... not modify it! unless you've got a database you're exposing to multiple parties and you're worried one is going to mess things up for others, but in that case i think exposing the database directly is pretty risky regardless. the application i've worked on with the most complex data constraints had an "ontology layer" that everything that wanted to do data access went through. the rest of the application got to ask very simple questions about what it wanted, or make very simple updates, and the ontology layer made sure everything was consistent before talking to the database. you get the benifits of having that work be centralized, not related to the core application logic (and thus not touched when ap logic changes), and you have a much better idea of what went wrong when a constraint failed. // Moreover such a dbfs should allow rapid development of // views over data (with different permissions) by simply // write the query in a file and then open the file for reading // the XML. somewhere around here i've got a /chan/pq for inferno that makes connections to a pq database. each open is a new logical connection; you write the query and read the result. results were not in XML, and pq has no updates (at current). i think you've got some very interesting ideas on sessionfs in particular. i have more thinking to do there. oh, probably an aside: from an application design point of view, DO NOT empty my shopping cart just because my session timed out. i should be able to pick up where i left off. i'm not sure how hypothetical that example was, but that's a common source of irritation for online shopping.
