design question

[Alex P <ap...@kolosy.com>]

kinda long, but here goes.

we're using couchdb for the back-end in friendsell.com. it's a social
marketplace site, so you have friends selling stuff to friends. the short of
it is that a single user can be friends with multiple other users, and can
specify who is allowed to see which of his items. what we do today is use
lucene, and do two layers of search:

query to lucene says "give me items that match query x AND are posted by
(user a, user b, or user c)", where the list in the parens is the full list
of friends the searching user has.

then, in the web app (.net) filter the list based on funky user settings
that say "i want friends to see items a and c, and family to only see item
b"

this works for the short term. my concern is that when friend lists get
large enough, we're going to be passing very large query strings to lucene.
i'm sure at some point there's a limit on url length, and in general
generating and then consuming such large boolean expressions via text isn't
very awesome.

another option i've considered is to calculate the full list of allowed
friends on item save, but it has the drawback of needing to review all items
every time your friend list changes (or friend classification changes), and
is also *very* verbose. 50 items for 50 users all of a sudden generates 2500
entries for no good reason.

the crux of the problem is that the stuff a user gets back is dependent on
the user, and involves some large set operations.

what are some other options? maybe redis in the middle of this (for the set
operations)? mysql? some view configuration i'm not seeing?

thanks,
alex.