So the relational model I mentioned would be the better option?

Its a pity there isnt a feature to select desired baseObjects and then
search within SubObjects linked to that object within a DataStore
call...

On Jun 5, 9:50 pm, djidjadji <[email protected]> wrote:
> One huge object would be very inefficient. You have to retrieve the
> whole lot every time you get() a BaseObject. You are limited to a
> total size of 1 Mbyte per object.
>
> Much cleaner is the approach with the two object Models. Now you can
> have an unlimited number of SubObjects and let the index do most of
> the work of fetching only the SubObjects that are important.
>
> 2009/6/5 mscwd01 <[email protected]>:
>
>
>
> > Hi,
>
> > I have a question regarding the best method of storing a complex
> > object which may grow to be very large in size.
>
> > I have an object 'BaseObject' which has a field of type
> > List<SubObject>. I wish to add many SubObject's to BaseObjects,
> > perhaps millions. When querying a SubObject I will first retrieve the
> > BaseObject and then perform a query on its list of SubObjects to find
> > the objects I need.
>
> > Now, is it a good idea to store objects in this way? I.e. having a
> > BaseObject which comprises an enormous list of SubObjects?
>
> > Another method of doing this would be to take the relational database
> > approach and have a BaseObject and SubObjects table where SubObjects
> > reference BaseObjects via an ID. However, I would really like to
> > maintain an object approach.
>
> > What are your views on this? Any feedback would be greatly
> > appreciated.
>
> > Thanks
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google App Engine" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-appengine?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to