0

Let C be a class that has another class D as its attribute. In principle, storing D as an embedded class of C must give better performance when retrieving than storing it as a separate entity through @ManyToOne (or even @OneToOne), since in the latter case, D needs to be retrieved from a separate table possibly containing millions of rows.

My question is whether this performance difference is significant, i.e. is it big enough to offset other considerations when deciding between embedding and @ManyToOne.

I realise this question is a bit soft, I guess what I'm looking for is people answering from experience.

oulenz
  • 1,199
  • 1
  • 15
  • 24
  • Why would storing it as an embedded give you better performance? Wouldn't this depend entirely on your database model and usage, and if you ever need to retrieve or search those embeddable fields? – Chris Sep 06 '16 at 14:15
  • Because then `D` sits *in the same row* as `C`, and no separate table needs to be accessed? I am sure there are scenarios where the difference is negligible, I am asking about scenarios where it is not. – oulenz Sep 06 '16 at 15:15
  • 1
    ManyToOne implies OneToMany backwards, so you are implying you are storing duplicate data in your rows. From an JPA perspective, it isn't an issue at all, but from your database and network perspective, this is essentially a subjective question about normalization. – Chris Sep 07 '16 at 14:05
  • Fair enough. Thank you for pointing out that this is essentially asking for the performance impact of normalisation! – oulenz Sep 07 '16 at 16:11
  • Possible duplicate of [What is the resource impact from normalizing a database?](http://stackoverflow.com/questions/1379340/what-is-the-resource-impact-from-normalizing-a-database) – oulenz Sep 07 '16 at 16:12

1 Answers1

0

My (soft too, like Your question) answer is 'allways make life simulation (model) in best possible way'. I set myself leading question: has 'a small class' independent life? Or is only conceptual glue (like street+home+local named Address)? Can be conceptually equal for many entities? Can bee 'small class' field nullable (address of mountaineers base in Himalayas) - nullable @OneToOne? Which Java model is better (real, natural)?

And I remember only one 'implementation question': is field of 'small class' always used (read) - very rare, can be serviced as Lazy, especially big. Move fields of sense 'Memo' varchar(4000) to extern table is good (with accessory fields: date, author of memo etc).

EDIT: how big is 'small class' and is rarely used?

In one project Address is correctly modelled as independent table, in other embedded.

Almost allays I have correct performance result with good logical model. Thinking about extremly 'only JPA performance' with logical errors give degradation is other place in code.

My opinion is: design by logical arguments. Performance may vary.

Jacek Cz
  • 1,872
  • 1
  • 15
  • 22