Few queries on atomicity of requests

[Daniel]

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 <memcached at puptv.com> 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