I would like some suggestions on data modelling
as an example lets say i have (hypothetical app)
Users
Sales
Sales items
and lets just say that maybe i have millions of users
millions of sales
and each sale could have 100 to 500 to 1000 to 10,000 and possibly a million
items - don't worry about items actually imagine the items being sold were users
how would i best model this as;
I'm a little confused as if your app needs to scale, is it best just to use
many
separate root groups and for example; just add a user key to the sales model a
sales key to the items model.
Now i know we can use a list property for the sales items (i said imagine they
were users) and we can do this but we will need lots of (rows) as one list
property cant hold our potential 1 million child's. and i know that with so
many
users and entities ill need to use a fork join queue. Oh and i should mention
the items must be in a list property i cant use lots of rows - entities.
All that i understand, i hope is clear.
What im confused about, is what is the best scalable / fast solution. The
documentation suggests don't use parent relationships if you don't need
transactions - and i don't.
It then suggests that that putting all your data into roots is also bad,
something about a handful of user data - have i read this wrong.
At the moment i have got things working using the keyname as a reference
for example i have a separate root for sales items - ie its not related to
sales
- i have really kept things split apart. as i can get most of my app data from
using key_names as paths.
class items(db.Model):
#key_name=path to the items from a sale like inv100/items
count=db.IntegerProperty(default=0)
class items_index(db.Model):
#key_name=path to the items from a sale like inv100/items/1
items = db.StringListProperty()
items=items_index.get_by_key_name(path_index,parent=parent_key)
#i can then just do get a few out of the items list and load them.
r=db.get(items)
As a note if i have an invoice:
key_name=inv100/
the items are
key_name=inv100/items/1
(i know that a parent of items is the first part of the url and the last part
is
the index - as i might have more than one entity if i need more than 5000)
The above is a mere simplistic example what i am keen to know is, well i know
it
works (might have a few bugs) but the concept work - does it scale?
Would it be better if rather than make a new root - i just add the items_index
to the sales root so like this
Class Sales(db.model)
.
.#all my sales properties here
.
.
count=db.IntegerProperty(default=0)
Class items_index
#key_name=path to the items from a sale like inv100/items/1
items = db.StringListProperty()
And then when i add indexes i can add Sales as a parent.
What is the best method for my needs?
I hope after than long winded explanation that's pretty much clear.
Regards
Martin Webb
The information contained in this email is confidential and may contain
proprietary information. It is meant solely for the intended recipient. Access
to this email by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken or omitted
in reliance on this, is prohibited and may be unlawful. No liability or
responsibility is accepted if information or data is, for whatever reason
corrupted or does not reach its intended recipient. No warranty is given that
this email is free of viruses. The views expressed in this email are, unless
otherwise stated, those of the author
--
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.
