Looking for a webapp framework that does away with the database_问答_开发者

I've been developing with Django during the last year or so and really enjoy it. But sometimes I find that the ORM is a bit of a straitjacket. All the data that I shuffle back and forth to the database would easily fit into 1GB of RAM. Even if the project grew a couple of orders of magnitude it would still fit into 1GB.

I'd like a solution where my application only needs to read from disk at startup but write开发者_高级运维s to disk implicitly as I update my objects. I don't care to much about any speed increase this might give me. What I'm really after is the added flexibility. If I have a problem that would fit nicely with a linked list or a tree or some other data structure, I shouldn't have to graft that onto a relational database.

Python would be nice but other languages are fine. I'm in the exploratory phase on this one. I want to get a feel for what solutions are out there. When googling this question I got a lot of hits related to different Nosql projects. But Nosql, as I understand it, is all about what you do when you outgrow relational databases because you've got too much data. I'm really at the other end of the spectrum. I've got so little data that a relational database is actually overkill.

Object databases is an other thing that came up when googling this question, which reminded me of Zope and ZODB. I dabbled a bit with Zope an eon ago and really disliked it. But reading up a bit on object databases made me think that it might what I'm looking for. Then again, their general failure to attract users makes me suspicious. Object databases have been around for a very long time and still haven't caught on. I guess that means there's something wrong with them?

If you are looking for "storing data-structures in-memory" and "backing up them to disk", you are really looking for a persistent cache system and Redis fits the bill perfectly.

If you want to use django, there is an awesome cache system built-in and that is pluggable to redis backend via Redis-Cache project. More over the data-structures accomodated by redis have one-to-one mapping to python data-structures, and so it is pretty seamless.

I am not so sure if skipping the concept of database itself, is a good idea. Database provides so much power in terms of aggregating, annotating, relations etc, all within acceptable performance levels until you hit real large scale.

Perhaps another idea would be to to use SQLite in-memory database. SQLite is so ubiquitous these days, it has disappeared into the infrastructure. It is built in, Android apps, iphone ones and has support from all standard libraries. It is also an awesome software developed and tested so well, it is very hard to make any case against using it.

The company I work for (Starcounter) creates a database that works exactly in the way that you describe. We have been running the database for a few years with our partner customers and are about to make the product publicly available. The main reason we created it is for ease of use and performance. I'll be happy to send you a copy if you send me a message on our corporate forum (I’m Starconter Jack). On the subject on OO databases; the reason that OO databases failed is mainly because they were more experiments than real products. They were poorly implemented, supported only the OO paradigm and ignored standards such as SQL and ODBC. They also lacked stability, performance and maturity. Their story is analogues to the early tablets, eBooks and smartphones a decade or two before the iPhone, iPad and Kindle. But just as with any technology, there are two waves (look up "the hype cycle"). While the first wave will disappoint, the second wave will be good. The first one will be driven by the concepts and ideas and will lack commercial success and real life usability. The second wave will want nothing to do with the musty smell of the failures of the first one and will therefore use new and fresh acronyms and buzzword. The future database will spring out of the NoSQL movement. It will have added SQL support and many will think this is novel. It will have added good language integration (and most languages are oo) and many will think this is also novel. It will support documents and many will think this will be novel. Many will rediscover the need for transactions etc. etc. Some grumpy old men will try to tell us that all we have done is to reinvent existing ideas. In some way they will be right; in some ways they won’t. This time around, the concepts are matured. New ideas will be added and pragmatism will be allowed. But then again, an iPad is still, in a way, a PDA.