Hi I feel like your taking the "Live Query" functionality, which does not scale especially well, and thinking that it applies to the main idea I'm presenting, which is a caching database daemon (CDD) that runs on many client machine, and combines memcached and each client machine, and interfaces with other CDD's and a core database.
Yes, the Live Query doesn't scale well, but is a feature that could be used when it's faster/better than running a knarly request routinely, or when a faster response is important. The database could probably watch for and create these automatically. --- Thanks for mentioning Django... I heard the name before but never really researched it. I take a look when I get a chance. Daniel On Sat, 2008-06-21 at 22:34 +0200, Henrik Schröder wrote: > On Sat, Jun 21, 2008 at 8:35 PM, Daniel <[EMAIL PROTECTED]> wrote: > In doing so, it will > have to do many requests to other CDD's for info on any joined > records, > and to alert other CDD's that have joined records that > changed, but who > cares as long as no additional requests go back to the core > database. > > Congratulations, you have just invented a distributed in-memory > relational database that does *not* scale linearly, and you think this > thing would somehow be faster than the existing relational databases > that can do exactly this? Memcached is fast because there are > absolutely no dependencies between cache servers, and because it is a > really simple storage for keys and values. What you suggest is the > opposite of that. > > I think you should take a look at Django or similar, you get an > object-relational mapper as well as a caching database framework, > which is even easier to use than plain SQL or ODBC, and you get a lot > of common usage covered by memcached automatically. > > > /Henrik Schröder