* Giacomo Tesio <[EMAIL PROTECTED]> wrote: Hi,
> The scope is to be able to query the db towards a filesystem, with no need > to use different libraries for different db backend... each application > would use a filesystem, while each rdbms would have it's own filesystem (all > with the same structure, obviously) That's a really good idea. But there's still one problem to solve: filesystem hierachies and relational algebra are fundamentally different concepts. So, if you don't want to just the fs as some universal sql-transport, data has to be modeled differently. Actually, in many webapps, the real underlying models are neither relational nor hierachic, but most times just happen to be modelled relatiolally, because rdmbs'es are the tool of choice for most people. So what we have to do here is to get back to the original problems to solve and think about how they could fit into an hierachy instead of relation. Simple example: a web-forum. Just look at how things were done in "good old" usenet times: boards/newsgroups are directories, postings are files. Maybe split off a single posting into several files, eg. to access single header lines or body parts (attachments, etc) separately. Now we're almost at mailfs ;) Okay, we've got some more data, eg. profile information, maybe all the other "web-2.0" stuff (user galleries, friend relations, etc), but IMHO this all easily fits in hierachies if we start thinking afresh with a blank paper. With hierachies we can do a lot of other fine things here, eg. server side threading (= postings ordered in a mail thread) or various kind of filtering/ordering - the client doesn't have to this all on its own anymore. Using symlinks (w/ 9P2k) might make it even more efficient. If we know certain objects/files won't be changed, caching can be come almost trivial, and the average traffic of some "web-2.0" application drops down to a very small percentage ... That's all possible, if we just can imagine it :) > Both are really important. > > When a product change its code (aka pk) for business' reasons, I need have > it changed automatically in any place its referred in the database. > Or if a dumb employee try to delete a product category (supposing he's > allowed) I have to be sure that the remaining data don't loose meaning. That's exactly what constraints, rules in SQL etc are for. Maybe some similar ruling system for filesystems would be fine :) (any suggestions ?) > Application should HANDLE data. > But datas are a rapresentation of a reality which have a meaning! > A relational database don't have to know how datas are collected or used. > But it has to keep meaningfull the rappresentation. Right. But the database has to know rules which data has to comply, so a wide range of errors becomes impossible, mathematically provable. Imagine a forum where each posting belongs into a board and is assiocated with the author. If the constraints are defined properly, the database won't ever allow postings w/o valid board or author. You could also define some rule which automatically removes all postings when the board gets deleted, at the same point of time. (of course, we're talking about real databases, cardfiles like mysql don't count here) > I need to be able to atomically save related tuples in different tables, > since (for example) those different tables could be simply modelling ONE > real entity (say an order or a family). CREATE RULE .. AS ON INSERT TO ... Again, a rule system for filesystems would be really cool :) cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ----------------------------------------------------------------------
