Hmm -- interesting, but a bit more at odds with the general concept. While Querki is radical, it's not *that* radical: it's a very strange database, but is still basically a database. Indeed, the QL language that you do queries in is probably going to turn out to be mostly isomorphic to SQL, although it breaks problems down in a very different way.
The way I often describe Querki is that it is to, eg, Rails just as a wiki is to a conventional website. It's a bit oversimplified, and not as powerful as the lower-level approach, but it's conceptually similar and much easier to use. The high-level concept is that there are many, many problems that are appropriate for a cloud-based database-centric website, but that aren't anywhere near complicated enough for such a big hammer. Those are the problems I'm mainly focused on -- the ones where a programmer goes, "But you should do that in a database!", but which people in practice mostly just throw into a spreadsheet, because they're not worth a huge amount of effort.
I'm kind of seeing what you're saying, but I'm not sure it's the problem I'm trying to solve here. At least not right now -- I could be convinced that it's worth tackling further down the road, but I'd need compelling use cases first. (One thing about a one-person company like this is that I am being *utterly* strict about not building anything unless I can understand the usage, and preferably the business case, very clearly.)
What you're describing is along the lines of some high-level concepts I'm playing with, where we start to treat all the descendant Spaces of an App as a larger pool of objects, but there are many more basic problems to solve before we get to that...
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2012-11-22 07:03 pm (UTC)The way I often describe Querki is that it is to, eg, Rails just as a wiki is to a conventional website. It's a bit oversimplified, and not as powerful as the lower-level approach, but it's conceptually similar and much easier to use. The high-level concept is that there are many, many problems that are appropriate for a cloud-based database-centric website, but that aren't anywhere near complicated enough for such a big hammer. Those are the problems I'm mainly focused on -- the ones where a programmer goes, "But you should do that in a database!", but which people in practice mostly just throw into a spreadsheet, because they're not worth a huge amount of effort.
I'm kind of seeing what you're saying, but I'm not sure it's the problem I'm trying to solve here. At least not right now -- I could be convinced that it's worth tackling further down the road, but I'd need compelling use cases first. (One thing about a one-person company like this is that I am being *utterly* strict about not building anything unless I can understand the usage, and preferably the business case, very clearly.)
What you're describing is along the lines of some high-level concepts I'm playing with, where we start to treat all the descendant Spaces of an App as a larger pool of objects, but there are many more basic problems to solve before we get to that...