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 wrote:
>
> Will G
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
O
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 wrote:
> It might not make "sence" but it certainly makes "sense" when you're living
> in
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
solutions
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 wrote:
>
> Maybe for performance the datastore as it is now is best.
> But when working
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 wrote:
> Some of the
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 be
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 se
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
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 H
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 C
PS: I read this interesting article
http://groups.google.com/group/google-appengine/browse_thread/thread/6106e26990a4a457/c0481c7c6629f8e8?lnk=gst&q=sum#c0481c7c6629f8e8
It's about calculating statistics at write time. Really interesting.
On 9 apr, 19:55, michaelg wrote:
> Horizontal scaling o
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 wrote:
> It might not make "sence" but it certainly makes "sense" when you're living
> in a world full of RDBMS, and want to make th
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 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
> hardware myself and
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 wrot
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 wrote:
>
> Maybe for performance the datastore as it is now is best.
> But when working with data (e.g. agg
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
wrote:
>
> I'm still not conviced the GAE datastore can suit my needs.
> I believe
> 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 yo
> 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.
>
19 matches
Mail list logo
