Objectify, efficient relationships. Ref<> vs storing id and duplicating fields

212 Views Asked by At

I'm having a hard time understanding Objectify entities relationship concepts. Let's say that i have entities User and UsersAction.

class User{
    String nick;
}

class UsersAction{
    Date actionDate;
}

Now in the frond-end app I want to load many UsersActions and display it, along with corresponding user's nick. I'm familiar with two concepts of dealing with this:
Use Ref<>,
I can put a @Load Ref in UsersAction, so it will create a link between this entites. Later while loading Users Action, Objectify will load proper User.

class User{
    String nick;
}

class UsersAction{
    @Load Ref<User> user;
    Date actionDate;
}

Store Id and duplicate nick in UsersAction:
I can also store User's Id in UsersAction and duplicate User's nick while saving UsersAction.

class User{
    String nick;
}

class UsersAction{
    Long usersId;
    String usersNick;
    Date actionDate;
}

When using Ref<>, as far as I understand, Objectify will load all needed UsersActions, then all corresponding Users. When using duplication Objectify will only need to load UsersActions and all data will be there. Now, my question is. Is there a significant difference in performance, between this approaches? Efficiency is my priority but second solution seems ugly and dangerous to me since it causes data duplication and when User changes his nick, I need to update his Actions too.

1

There are 1 best solutions below

2
On BEST ANSWER

You're asking whether it is better to denormalize the nickname. It's hard to say without knowing what kinds of queries you plan to run, but generally speaking the answer is probably no. It sounds like premature optimization.

One thing you might consider is making User a @Parent Ref<?> of UserAction. That way the parent will be fetched at the same time as the action in the same bulk get. As long as it fits your required transaction throughput (no more than 1 change per second for the whole User entity group), it should be fine.