big table parent-child

if have i have pojo like categoryA -> subcategoryA--> book r开发者_如何学编程elationship. subcategoryA is child of parent categoryA. book is child of subcategoryA in this case, everything is inside same entitygroup

if i need to move 'book' to another subcategory-B. i need to delete subcategoryA and categoryA, and recreate categoryA -> subcategoryA--> without book ? and recreate categoryb -> subcategoryb--> book ,other-book, other-book3 ?

---

If 'book is child of subcategoryA' and you have modeled this by adding subcategoryA's key to book's key-path, you either need to delete/recreate book, or you need to create a subcatagoryB with the same key as subcatagoryA originally had. This would affect all other books that were child of subcatagoryA.

This is because (citing appengine docs: "The complete key is assigned when the entity is created in the datastore, and none of its parts can change.").

Both solutions to me seem as quite tricky, and I suggest that you rethink your design. For instance, you could store subcatagoryA's key as a seperate field inside a separate property. This has down-sides as well, which you could partly solve by denormalizing your data and storing (part of) subcatagoryA's data directly INSIDE book.

[EDIT]

In response to your question: the disadvantage of small entity groups is that you can not use transactions. Whether this is a problem depends on...whether you really need transactions on books+((sub)categories. A bigger problem of denormalization comes up when you want to change something of your denormalized data. For this, you could come up with a scheme like this:

• store each category as an entity with properties. Store the category KEY + (some of) the other properties with your book(s).
• If a category changes, update all denormalized data of all books belonging to that category (used stored 'foreign' key to find these books)
• Use a cron job to check for consistency in the background (ie for cases where the previous job fails mid-way).