Pushing calculations from read time to write time makes sense in that reads
seriously out number writes for most web applications.
Pushing calculations at write time instead of read time has some other
very very strong implication that you're probably missing: that you
know in advance what you
In the business environment
it's often not know, and the flexibility in this regard provided by
relational databases is part of what has made them so popular.
Only if the schema makes it possible to get what you want. And, even
if it does, the cost may be excessive.
http://googleappengine.blogspot.com/2009/02/back-to-future-for-data-storage.html
Down with RDBMS'! (no, they didn't say that:D )
On Apr 8, 8:58 pm, Andrew Badera and...@badera.us wrote:
It might not make sence but it certainly makes sense when you're living
in a world full of RDBMS, and want
I can definitely see your need. I know Heroku offers this kind of
service, if you don't mind using Rails :-)
On Apr 9, 1:41 pm, Marcel Overdijk marceloverd...@gmail.com wrote:
Hi Micheal,
Just 1 db is fine enough for me.
I would choose a cloud platform because I don't want to maintain the
I'm still not conviced the GAE datastore can suit my needs.
I believe I can do the same at the end of the day, but with a lot of
more manual work...
So I'm still not sure if I will go with GAE or some other solution
(Java hosting like Mor.ph, or PHP) as alternative.
On 10 apr, 19:00, ctran
Marcel,
Many high performace scalable efficient web 2.0 websites developers
recomend no using sum, avg, etc aggregate functions functions.
On Wed, Apr 8, 2009 at 4:31 PM, Marcel Overdijk marceloverd...@gmail.comwrote:
Maybe for performance the datastore as it is now is best.
But when working
What do you mean by manual work?
Pushing calculations from read time to write time makes sense in that reads
seriously out number writes for most web applications.
On Sat, Apr 11, 2009 at 8:47 AM, Marcel Overdijk
marceloverd...@gmail.comwrote:
I'm still not conviced the GAE datastore can suit
Horizontal scaling of relational databases is non-trivial and Google
does not offer it. I can't say if they have something internally that
could work for some people, but it is such a tricky subject that it
would be hard to offer a general purpose, turnkey solution. As an
example, Google donated
Hi Micheal,
Just 1 db is fine enough for me.
I would choose a cloud platform because I don't want to maintain the
hardware myself and install os, application server etc.
Or even worse have to put up another application server and have to
load balance it.
That's why I like the elasticity of the
PS: I read this interesting article
http://groups.google.com/group/google-appengine/browse_thread/thread/6106e26990a4a457/c0481c7c6629f8e8?lnk=gstq=sum#c0481c7c6629f8e8
It's about calculating statistics at write time. Really interesting.
On 9 apr, 19:55, michaelg mike...@gmail.com wrote:
I doubt it. New features may be added to the datastore to make it
similar, but it wouldnt make sence to have two database backends.
(for the record it doesnt support BigTable now - it provides the
DataStore which is something different)
IMHO.
On 08/04/2009, Marcel Overdijk
It might not make sence but it certainly makes sense when you're living
in a world full of RDBMS, and want to make the barrier to entry as low as
possible.
Thanks-
- Andy Badera
- and...@badera.us
- Google me: http://www.google.com/search?q=andrew+badera
Sent from Albany, NY, United States
On
Maybe for performance the datastore as it is now is best.
But when working with data (e.g. aggregate functions like sum, avg
etc.) a relational database has also advantages.
On 8 apr, 19:58, Andrew Badera and...@badera.us wrote:
It might not make sence but it certainly makes sense when you're
Some of the same problems can be solved in different ways. For instance,
aggregate data can often be calculated at write time, obviating the need for
an expensive aggregate runtime query involving millions of records and
hundreds of machines. The tricky bit is implementing the different
Note that aggregate functions are a feature often implemented on a
RDBMS, but they could be implemented on the Datastore (eg using
covering indexes) without being relational.
On 08/04/2009, Marcel Overdijk marceloverd...@gmail.com wrote:
Maybe for performance the datastore as it is now is
Right, but that doesn't address the ignorant masses, clamoring for their
Google cloud.
There are plenty of ways to solve any problem ... but the issue of barrier
to entry is not one that is solved by higher level thinking :)
On Wed, Apr 8, 2009 at 3:40 PM, Dan Sanderson
The datastore implementation (non-relational) is one of the last
things I'm bumping against (now Java is supported ;-)
I understand that aggregate data *can* be calculated at write time.
But this is not what I want and I guess a lot of other users will
think the same.
Also adhoc querying will
I agree that the datastore is not good for adhoc runtime queries. The
datastore was designed to maintain its performance characteristics
independent of the number of entities stored, including query performance.
(The performance of our index-backed queries is a factor of the size of the
result
Thanks for your clarification Dean.
But there are no plans at Google to support a relational persistent
store?
I think it would be good if both are supported.
For some applications I agree a relational database is not required,
but for the kind of application I would like to write I think can't
19 matches
Mail list logo
