We Keep Coding

JPA/Hibernate ManyToMany vs two-sided OneToMany/ManyToOne

I am developing a JavaEE application and I use JPA/Hibernate as a persistence engine. While developing the application, some questions raised to my mind.
The application consists of users and their roles in a N:M relationship. Here is the database subset of the above tables.
I am relatively new to Hibernate and at first I asked IntelliJ IDEA to generate the mapping for me. What it did was generate the following Java classes:
UserEntity.java
RoleEntity.java
UserXRoleEntity.java
UserXRoleEntityPK.java
Thus, it generated a mapping for the relation table and two 1:N relationships, one between user and userXrole and one between role and userXrole.
After some research, I found that, by using the #ManyToMany annotation, I could omit mapping the userXrole table into a Java class and just declare it within the annotation as the #JoinTable.
So the question is:
Why does IntelliJ generate the entities that way?
Is it just a more generic way that helps generation, or does it have any other advantages. Would you argue in favour of one way or the other?

Is it just a more generic way that helps generation, or does it have any other advantages.
JPA doesn't know if a table is just a join table, that's why you have to tell it (using #JoinTable). The generator might guess, but it will probably only generate #ManyToMany if your table names match JPAs defaults.
Would you argue in favour of one way or the other?
I'd use #ManyToMany if i don't have a reason (finer grained control over lazy/eager fetching maybe?) for separate mapping entities, mostly because less code = less errors.

How to use prefix table names with jpa

I'm using java play to make a web application and I'm having some trouble persisting data using ebeans and jpa annotations.
I've searched a lot, and I'm a little confused, I think that this is something that should be common, I want to have tables named like this:
company 1_users
company 2_users
company N_users
but I want to have only one entity named user, can be possible to have this schema ?
I've searched about using one entity with multiple tables, about using table name prefixes and about using dynamic table name but I got nothing helpful.
Some ideas ??

As #GlennLane said in comment, creating separate tables isn't good idea, instead use some field as a company id/discriminator. You will save tons of nerves, and you won't need to update your code each time when new company joins the branch.
If you really want separate tables create separate model for each company, at least you won't mishmash that in code.

Converting database data into objects

I'm building my first real Java application, and I'm confused about following good object-oriented design practices.
My application allows a yoga instructor to design a yoga session. There is a MySQL database with five tables:
a table of yoga poses,
a table for the warmup section of the session
a table for the work section of the session
a table for the restore section of the session
and finally a table containing the various yoga sessions the user has created.
The sessions are composed of sections, and the sections are composed of poses. I purposefully chose to use a database in this design rather than lists or arrays for the purpose of learning how to integrate a database with Java.
Here is my question:
Is it really necessary to make objects out of the poses, sections and sessions?
They are merely data, and they don't have behavior of any kind. The real objects in my application are the windows and tools the user is using to assemble these poses and sections into yoga sessions. It just seems that my code will become unnecessarily inflated and complicated if I force each pose and section and session to be an object. I realize that I may be asking for opinions here, and that is generally discouraged on this forum. But my intent is to understand and follow object-oriented design in what seems to me to be a murky area.

To answer your question, Yes, create objects for each. The main principle of Object oriented programming is having different "types" of Objects and doing stuffs (Behaviors - methods) around them.
I suggest you to look at the concept of ORM. ORM is the process of mapping Objects to their persistent representation, i.e Database tables.
If you go for plain JDBC, you may need to write a lot of native SQLs and code to extract individual column's values from your table. When the complexity of your schema increases, it will get difficult to maintain these queries.
With ORM, you can write simple java programs to get and save data from persistent layers.
You can go through this thread to look at the ORM advantages
Hibernate is a great framework available for Java which does ORM

1) If you use Hibernate or other ORM, you must use POJOs. There's no other way.
2) If you use JDBC directly, for example Spring JDBC, you could use maps (SimpleJdbcTemplate returns maps in many functions etc.), but reading POJO field is much quicker and less error-prone than reading field from map. Maps take also more place in memory.
3) If you are using JSF, you need POJOs with getters and setters, maps could theoretically be used for read-only, but the syntax is going obscure.
Reassuming, there's no good alternative for POJOs in Java for storing datas. In some cases you can use maps, but it's good only when the data structures are dynamic or as temporary solution.

Mapping POJO to Entities

In our project we have a constraint of not having the luxury to alter the table structure already in place. The tables are highly denormalized in nature.
We have come up with good POJOs for the application. We have the Entity beans generated out of the exiting tables. Now we have to map the POJOs to the entities so that we can persist.
Ultimately, we combine a good POJO with a bad table. Any thoughts on options/alternatives/suggestions to this approach?

Hibernate/JPA(2) has a rich set of functionality to manipulate the mapping (so that your objects can differ from the tables), so that many (NOT ALL) old tables can be mapped to normal object. -- May you should have a look at this first, any use your pojo/table-"solution" only if this mapping is not powerful enough.
If you have a read only application, you can think of using views to make your table/views more like you objects. This may reduse the amount of strange mapping.
I don't know your mapping, size of the application or use case, but have you considered not to use Hibernate? I ask this, because I can imagine (how I said: I don't know you application), that in a architecture like this, no Hibernate feature is used and so Hibernate will add only a not needed complexity.

If you are using Hibernate you should be able to map your POJOs to the table structure using only XML files, without creating new Java beans. This would allow you to easily change the mapping if all of a sudden you can change the tables structures and make the economy of intermediary beans. That's the best you can do.

Creating tables dynamically in Hibernate environment

There's an enterprise application using Java + Hibernate + PostgreSQL. Hibernate is configured via annotations in the Java source code. So far the database schema is fixed, but I faced the problem that it needs to be dynamic:I can receive data from different locations and I have to store these in different tables. This means that I have to create tables run-time.
Fortunately, it seems that all of these data coming from the different institutes can have the same schema. But I still don't know how to do that using Hibernate. There are two main problems:
How to tell to Hibernate that many different tables have the same structure? For example the "Patient" class can be mapped to not just the "patient" table, but the "patient_mayo_clinic" table, "patient_northwestern" table, etc. I can feel that this causes ambiguity: how Hibernate knows which table to access when I do operations on the Patient class? It can be any (but only one) of the former listed tables.
How can I dynamically create tables with Hibernate and bind a class to them?
Response to suggestions:
Thanks for all of the suggestions. So far all of the answers discouraged the dynamic creation of tables. I'll mark Axel's answer, since it achieves certain goals, and it is a supported solution. More specifically it's called multi-tenancy. Sometimes it's important to know some important phrases which describes our problem (or part of our problem).
Here are some links about multi-tenancy:
Multi-tenancy in Hibernate
Hibernate Chapter 16. Multi-tenancy
Multi-tenancy Design
EclipseLink JPA multi-tenancy
In real world scenario multi-tenancy also involves the area of isolating the sets of data from each other (also in terms of access and authorization by different credentials) once they are shoved into one table.

You can't do this with Hibernate.
Why not extend your patient table with an institute column?
This way you'll be able to differentiate, without running into mapping issues.

I am afraid you can't do this easily in Hibernate. You would have to generate the Java source, compile it, add it to your classpath and load it dynamically with java.reflection package. If that works, which I doubt it, it will be an ugly solution (IMHO).
Have you consider using a schema less database i.e: NoSQL databases or RDF
databases. They are much more flexible in terms of what you can store in them , basically things are not tight up against a relational schema.

In most environments it is not a good idea to create tables dynamically simply because dbas will not give you the rights to create tables in production.
Axel's answer may be right for you. Also look into Inheritance Mapping for Hibernate.

I agree that its not advisable to create tables dynamically nevertheless it's doable.
Personally i would do as Axel Fontaine proposed but if dynamic tables is a must-have for you I would consider using Partitioning.
PostgreSQL allows you to create ona main table and few child tables (partitions), records are disjunctive between child tables, but every record from any child table is visible in parent table. This means that you can insert rows into any child table you want using just simple insert statement (its not cool but has the same level of complexity as composing and persisting an entity, so its acceptable in your case) and query database using HQL