Right, denormalization is promoted by the Max Ross video as in your
2nd case so from a software design perspective can the "copy fields"
in Employee be contained in their own class and referenced from
Employee in a fashion that allows JDO to still work such as:
class CompanyFK {
// copy of property fiels from Company
@Persistent private String companyName;
@Persistent private String businessArea;
@ManyToOne
private Company company;
}
class Employee {
@Persistent String name;
@Persistent String address;
CompanyFK compnayFK
}
This way all entities that include a FK to Company would use CompanyFK
and denormalized relations such as this would be managable (ie rather
than copy/paste of fields across many Entities). Does JDO allow this
level of control?
On Sep 7, 4:44 am, leszek <leszek.ptokar...@gmail.com> wrote:
> I'm not sure if your taking of the problem is correct. To my mind it
> runs:
>
> You have Company and Employee. Company has many Employees and Employee
> is working for one company. "Normalized" version looks like:
>
> class Company {
>
> �...@persistent private String companyName;
> �...@persistent private String businessArea;
> ...
>
> }
>
> class Employee {
>
> @Persistent private String name;
> @Persistent private String address;
> ....
> @ManyToOne
> private Company company;
>
> }
>
> If you want to get all Employess working for a company you should
> execute:
> "SELECT * FROM Employee e WHERE e.company.companyName = :nameParam"
>
> or if you want all Emloyees working for all IT companies you execute:
> "SELECT * FROM Employee e WHERE e.company.businessArea = 'IT' "
> ...
> But this query will not work in Google App Engine.
>
> The solution is to resolve this query programmaticaly by running
> several queries and filter it in memory or to "denormalize" this
> scheme by moving some fields from Company to Employee
>
> Something like:
>
> class Epmloyee {
> @Persistent String name;
> @Persistent String address;
>
> // copy of property fiels from Company
> @Persistent private String companyName;
> @Persistent private String businessArea;
>
> @ManyToOne
> private Company company;
>
> }
>
> and run
> "SELECT Object(Employee) FROM Employee e WHERE e.companyName
> = :nameParam"
>
> The first solution allows keeping "normalized" version but the cost is
> less effective query, the second requires to break strictly normalized
> pattern but the query is much more effective (I think that it can be
> 10 or more times more effective). Also the second solution requires
> more time while writing and updating.
> But it is up to you what is more important, it is classical dilemma:
> more "reads" or more "writes".
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-java@googlegroups.com
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en
-~----------~----~----~----~------~----~------~--~---
