jasondb, a RESTful database(jasondb.com)
jasondb.com
jasondb, a RESTful database
http://www.jasondb.com/jasondb/jasondb.html
4 comments
So this is not a database, per-se, but a document base?
If I have to wrap every data element in a file, doesn't that add overhead?
Honestly, what's the benefit to me of this over say, SVN+HTTPS with 10 minutes of config?
Interesting idea, since most websites at the start rely almost entirely on simple CRUD operations. However, this is extreme lockin of an application's foundation, which is why I would never consider it.
How is this any different / better then using CouchDB and hosted CouchDBs at CouchOne?
the least important or interesting parts of a db are its api and storage format
What is a database, if not an API for a storage format?
the stuff between the two is pretty important
I was hoping for something more specific; am example might be "the query optimizer". Seriously: most everything about a database solution is determined by its storage format, whether it be how it handles concurrency, how it scales, how it handles catastrophic events like power loss, or how expensive it is with regard to memory, disk, and I/O between.
Sitting down and really thinking about what is in, for example, PostgreSQL, that isn't defined by its storage format, the one thing I've come up with so far is query optimization, which I will agree is important, but certainly not /more/ important than the storage format (especially given how many people, even on this site, seem to want to bypass the optimizer, given comments on a recent thread here).
(For a commercial solution I could also see "licensing costs", and generally I could also see "engineering build quality", but that latter notion is unlikely to ever be self reported as "poor, our engineers suck, and we fully expect there to be numerous race conditions in our concurrency code: buyer beware".)
Sitting down and really thinking about what is in, for example, PostgreSQL, that isn't defined by its storage format, the one thing I've come up with so far is query optimization, which I will agree is important, but certainly not /more/ important than the storage format (especially given how many people, even on this site, seem to want to bypass the optimizer, given comments on a recent thread here).
(For a commercial solution I could also see "licensing costs", and generally I could also see "engineering build quality", but that latter notion is unlikely to ever be self reported as "poor, our engineers suck, and we fully expect there to be numerous race conditions in our concurrency code: buyer beware".)