Which is better of MANY_TO_ONE and ONE_TO_MANY

Question

I am trying je.
A little confuse is , that suppose A has one_to_many relation to B, then B can have many_to_one relation to A. And both solution is acceptable to my application. Which should I choose?

Answer 1

Hello Jie,
This is a very good question, since we do not describe in the documentation how to choose between MANY_TO_ONE and ONE_TO_MANY. As you point out, it can be done either way when a related entity is used.
For example, here is how MANY_TO_ONE can be used:
@Entity
class Person {
  @PrimaryKey(sequence="ID")
  long id;
  @SecondaryKey(relate=MANY_TO_ONE, relatedEntity=Employer.class)
  long employerId;
  String name;
@Entity
class Employer {
  @PrimaryKey(sequence="ID")
  long id;
  String description;
}Of course we will need primary indexes for both entities:
PrimaryIndex<Long,Person> personById = ...;
PrimaryIndex<Long,Employer> employerById = ...;To get the employer of a person, we simply pass the employerId to the primary index:
Person person = ...;
Employer employer = employerById.get(person.employerId);To get the employees for a given employer, we get a sub-index for the employerId secondary key:
long anEmployerId = ...;
SecondaryIndex<Long,Long,Person> personByEmployerId = ...;
EntityIndex<Long,Person> employees = personByEmployerId.subIndex(anEmployerId);
EntityCursor<Person> cursor = employees.entities();
try {
  for (Person employee : cursor) {
    // do something with employee
} finally {
  cursor.close();
}And here is how ONE_TO_MANY can be used to provide the same functionality:
@Entity
class Person {
  @PrimaryKey(sequence="ID")
  long id;
  String name;
@Entity
class Employer {
  @PrimaryKey(sequence="ID")
  long id;
  @SecondaryKey(relate=ONE_TO_MANY, relatedEntity=Person.class)
  Set<Long> employeeIds;
  String description;
}To get the employer of a person, we simply pass the person id to the employer's secondary index:
Person person = ...;
SecondaryIndex<Long,Long,Employer> employerByEmployeeIds = ...;
Employer employer = employerByEmployeeIds.get(person.id);The primary difference is that with MANY_TO_ONE the collection of employee IDs is maintained by the secondary index, while with ONE_TO_MANY the collection of employee IDs is embedded in the Employer entity.
Therefore to get the employees for a given employer with ONE_TO_MANY, we get the Employer object from the employerById primary index and then get each person in the employeeIds set:
long anEmployerId = ...;
SecondaryIndex<Long,Long,Person> personByEmployerId = ...;
Employer employer = employerById.get(anEmployerId);
for (long employeeId : employer.employeeIds) {
  Person employee = personById.get(employeeId);
  // do something with employee
}There is a major difference in terms of performance and scalability. With ONE_TO_MANY, if the number of employees for a single employer is very large, then the Employer record will be large because the list of employee IDs is embedded in the Employer object. This means that it will be more expensive to load the employer, for example, if all you want is the employer description field. The list of employee IDs will always be loaded whenever you access an employer.
On the other hand, with MANY_TO_ONE, the set of employers is stored in the sub-index. The sub-index is a Btree. It is very scalable and can easily support large numbers of employees per employer, even millions. And when simply loading the Employer record, the set of employeeIds for that employer will not be loaded. The Employer record will be very small.
There are four factors in deciding whether to use MANY_TO_ONE or ONE_TO_MANY.
(1) As shown above, it is slightly easier to use ONE_TO_MANY, because you don't need to use a sub-index as you must do with MANY_TO_ONE.
(2) MANY_TO_ONE will scale to larger number of entities per relationship, since a sub-index Btree is used to store the related entities.
(3) With MANY_TO_ONE, the entity object will not grow to a large size as many related entities are added. Smaller records are always better for performance and resource consumption.
In general, I advise using MANY_TO_ONE because it does not have the potential performance problems of ONE_TO_MANY (items 2 and 3 above).
But if you know that the number of related entities per relationship will be small, then either technique works well, and you should choose whichever you prefer. You may find that ONE_TO_MANY is slightly easier to use (item 1 above). Or you may choose one technique over the other because you prefer to maintain the relationship via the Person.employerId field or the Employer.employeeIds set.
There is one additional factor. If you have a secondary key where there is no related entity, just related keys, then you have no choice. There is only one entity, and you choose the relationship type accordingly.
For example, a Person may have many email addresses, and you may choose not to have an EmailAddress entity. The email addresses are simply secondary keys, not the key of another related entity. If a user can only have one email address, you would use ONE_TO_ONE. If the user can have multiple email addresses, you would use ONE_TO_MANY as shown below.
@Entity
class Person {
  @PrimaryKey(sequence="ID")
  long id;
  @SecondaryKey(relate=ONE_TO_MANY)
  Set<String> emailAddresses;
  String name;
}A gender (male or female) secondary key is an example of a MANY_TO_ONE relationship where no related entity is involved:
@Entity
class Person {
  @PrimaryKey(sequence="ID")
  long id;
  @SecondaryKey(relate=MANY_TO_ONE)
  char gender; // M or F
  String name;
}In this last example, there is no choice about whether to use ONE_TO_MANY or MANY_TO_ONE because there is only one entity involved. So this last rule is:
(4) If there is no related entity, then because there is only one entity involved the relationship type is determined by the cardinality (number) of entities and keys in each relationship.
Mark