Documents-oriented architecture and hibernate. Starting point

Question

I want to create architecture like this (abstract scheme):

abstract class Document
 - number
 - autor
 - createDate

class Order extends Document
 - cost
 - client

class Discount extends Document
 - value

...

Should Document class have annotation @MappedSuperclass (no table for Documents), or it should have it's own table - One-to-One relation with concrete entities?

Is there some ready templates for documents-oriented system on java+hibernate, or some good examples?

As an aside, if you're working with documents, you should probably (briefly) consider using [JCR](http://stackoverflow.com/questions/3908584/when-to-use-jcr-content-repository-over-other-options). It has some advantages for dealing with hierarchically organised objects containing lots of text. It has the big disadvantage of being yet another API to learn. — Tom Anderson, Aug 26 '11 at 09:03

score 1 · Answer 1 · answered Aug 26 '11 at 08:59

Does your application deal with documents, or does it deal with orders and discounts. For example, do you have some page used to search and display documents, regardless of their type? Or do you have some other entity which has an association (ToOne or ToMany) with a document (and not with an order or with a discount)?

If the answer to one of these questions is yes, then Document should be an Entity (which doesn't mean it should have its own table: Hibernate supports three types of inheritance mapping for entities).

If, in fact, Discount and Order are two unrelated entities which just have a common set of attributes (number, author and creation date), the Document should just be a MappedSuperclass.

+1: The key question is whether you need to deal with Documents polymorphically at the JPA level. — Tom Anderson, Aug 26 '11 at 09:04

Documents-oriented architecture and hibernate. Starting point

1 Answers1