http://bitbucket.org/wkornewald/django-nonrel-multidb/

http://www.fossil-scm.org/fossil/doc/tip/www/theory1.wiki

I think part of the attraction of using SQL is that you can switch backends, so you don’t want to use Postgres-specific features because that would tie you down.

On the other hand, once you’ve picked, say CouchDB, there’s really nothing else you could easily switch to, so you might as well take full advantage of CouchDB’s power. (And we’re not going to mention anything about not _actually_ being able to easily switch to a different SQL backend.

I think apps requiring great flexibility should make more frequent use of the State pattern, delegating persistence to ORM objects but retaining model logic. I think the additional layer of indirection affords the flexibility needed to solve problems like the tagging problem, because a domain object like a bug report can delegate to more than ORM object, and be easily decorated by things like “Taggable,” when you want to avoid having multiple tag namespaces.

On a separate note, I’m not sure I follow your logic about not using e.g. Postgres’s full power. If Postgres had an extension that fixed your problem, why would it be worse to be tied to it than it is to be tied to one specific NoSQL program?

But your blog does bring out the fact that I need to do a better job of explaining the concepts behind Fossil and perhaps even use the word “NoSQL” someplace in the Fossil documentation. I’ll work on that after the Christmas break….

1. NoSQL – exactly as Greg says: if you’re going to use this stuff, abstracting away the platform doesn’t make sense.

2. *SQL – for things that SQL does well, one probably should continue to use it even in a NoSQL application, e.g. account management. And there’s no point here complaining that you can’t do joins from the *SQL to NoSQL world (e.g. again, to map say a user account into NoSQL rows), since normalization, joins, etc are what you gave up to gain the NoSQL features.

3. Common stuff – independent of whether one is doing *SQL or NoSQL applications, or hybrids, there’s things that are common to both/all: paging through results (row level stuff), displaying results in templates (row data stuff), and so forth. Here’s where we’d like to see common code, no matter what the back end that’s providing the data. Unfortunately, there’s probably very few people with the synthesis knowledge and reputation to adapt Django to this right now.

There are lots of tools that use zodb, and you can even use sql dbs as a backend if you like (with relstorage).

Personally I’m using a very simple key/value store. ( see http://renesd.blogspot.com/2009/12/pywebsitesqlitepickle-sqlite-vs-pickle.html ) Since zodb does not support python3 and there seems to be no roadmap for doing so.

http://www.sqlalchemy.org/docs/05/mappers.html#mapping-class-inheritance-hierarchies