I found in a presentation on http://www.ericburke.com/hibernate/hibernate.pdf in the section "When not to use hibernate" the following statement:

"A horrible database design is forced on you
○ Many composite keys"

My question is now: Is this also your advice so the usage of Hibernate is more or less difficult/exhausting with a lot of composite keys?

Under which use-cases or circumstances do you think you would use/not use Hibernate for your applications?

I am thinking about, because I have to decide if I use Hibernate for an application on a database containing only tables with (primary-)keys containing three to eight columns.

I am asking because on all Websites and documentations I found in the Internet for Hibernate, it is always described as all-in-one device suitable for every purpose. I found no section telling me: Better not use for this or that. (Only the above mentioned source.)

Thank you for sharing your experience with me!

Yours

Christian

I'm not the most experienced Hibernate user, but I've spent the last month doing nothing but Hibernate stuff for work. I'm also new to it which means I've just experienced the things you are probably about to encounter.

Where I work our DBAs mandate "no table will have a surrogate primary key. All tables will have composite-keys which represent the data. The use of sequence numbers is forbidden unless it is proven through extensive effort and research that a solution without a sequence is impossible or too difficult to use."

With that said, my current project has about 12 tables and views and about 16 value objects which I map to our tables/views (Some of these value objects are abstract.). Dealing with composite keys wasn't that hard actually, despite what the docs said. Our tables actually use about 5 different composite-keys and they all fit within a heirarchy so classing them out was a snap.

I've posted a few examples of how I've used composite keys in this forums so you can search and get an example with full code and xml based on my username.

No, Hibernate isn't the end-all-be-all solution. It's quite good though. We've found at work that Hibernate works very well for small and mid-sized apps but it blows up on our large applciations. This isn't necessarily a Hibernate issue but the amount of data we're talking about (a query for about 70,000,000 records isn't uncommon and pulling a TB of data isn't really eye-popping). Our genaral rule of thumb is Hibernate will be a great solution if our results will number in the thousands or lower. Anything else and it tends to bog down.

However I will add that my employer is rather unique with regard to our size and what works for others doesn't work well for us. Just ask our vendors!

HTH

Your DBAs need some education on fundamentals if they favor natural keys. Of course its a way to keep your job, as you create maintenance problems as you go along. Even Chris Date, who in his older material favored natural keys, is now considering surrogate keys a preferred solution.

Note that fetch behavior, or the number of records fetched, does not in any way influence Hibernate's performance if you use the right fetching strategy. If its not working well, you probably missed something very essential in Session and Query handling.

Nothing that I haven't said/thought. But our DBAs have more experience in DB work than I have experience with life. People generally don't like to change. I totally agree that surrogate keys are a better solution simply because it's easier to see the relations and you have less data simply copied along. In my current app, the majority of our comp-keys are 3 elements and in each table those 3 elements have columns -- so we have a bit of duplicate data.

Would you kindly forward (through this post is fine) your source for Chris Date's considering of surrogate keys as a preferred solution? I suspect this is in a newer book but the Date books I have are a bit dated. I'd be very much interested to learn what he thinks on this matter if his opinion has changed and very grateful for this.



That could be, I won't deny it. Let me point out that this isn't my experience but others here that have more Hibernate experience than myself. I've also read in various articles and books (most recent Tate and Gehtland's Spring A Developer's Guide) that Hibernate isn't the best solution for large applications.

I don't have any book reference but from the exchange I read at www.dbdebunk.com when he is involved, he seems to suggest that he prefers surrogate keys if there is no reason to use natural keys. Pascal always preferred surrogate keys first, and I really follow his opinion that you would have to find a good reason to use natural keys, not the other way around. I think it is clear why composite keys should be avoided. A coherent approach in a particular database with natural keys often requires composite keys.

Get the small Pascal book "Practical issues in database management" for a primer on many important issues.

I haven't read anything from Tate or Gehtland, but yes, Bruce was very vocal about his opinion, and I think he still posts this without any justification from time to time. Last year Gavin, Bruce, and I had a short email exchange about this - after we really begged for it, he sent us a list of things why he considers Hibernate not good for "large applications". I don't have this anymore as it was really not very, well, let's say "helpful".

We have customers with 1000K tables, billion dollar projects, and hundreds of developers using a Hibernate persistence layer (usually only a small team is concerned with developing the persistence layer). They seem to be pretty happy, and indeed helped us remove some of the issues Hibernate had in large-scale applications over the past years. Today, we don't know about any bigger issue, with "startup time with thousands of entities" being the worst problem I can currently remember.

There is absolutely no problem using composite keys in HB3. Back in HB 2.x, there used to be a "trick" you needed which for some reason was simply impossible to master for a certain group of users. This trick is no longer required.

No solution is. The point of Hibernate is that you can use it to solve upward of 95% of data access problems in your app, and use other techniques (direct JDBC) for the remaining cases.



This is not an issue of the "size" of the application. Or even of the size of the tables. We have people successfully using Hibernate in huge projects with enormous databases.

What it is is an issue of the kind of application. We have never tried to tell people to use Hibernate < 3.1 for batch/bulk processing work. Hibernate is for typical, traditional OLTP work, where the data set you use in a single transaction is "small".

Now, if you want to use HB 3.0 with very large datasets (against our advice) you can read:

http://www.hibernate.org/hib_docs/v3/re ... batch.html

which tells you how to do it successfully.

But, our advice for 3.0 remains that you should use JDBC/stored procs/whatever for the batch part of the application, and Hibernate for the OLTP part.

Now, HB 3.1 is a completely different beast. The main goal of 3.1 is to support large sets of data in the batch/bulk processing scenario. Hence we have introduced StatelessSession API, very sophisticated HQL INSERT/UPDATE/DELETE query support, "large" collection support (lazy="extra), break processing (collection FETCH JOIN with scroll()), HQL WITH clause, etc.

We expect that 3.1 will be useable outside the traditional OLTP realm where ORM solutions have traditionally had a sweet spot.



My measurements show problems when the number of "small" objects exceeds 50 000. Could be less for "large" objects. Again, no OLTP application can display 50 000 objects to the user at once ;-)

In 3.1, StatelessSession is not limited in this way.

This is completely bogus. Hibernate makes most sense in applications with large data models (ie. many tables), large teams, applications with complex business logic, and applications which work with deep graphs of data.

We have plenty of successful customers to demonstrate this fact.

"Small" applications (esp. apps with few tables) is exactly the usecase where we tell people to not use Hibernate.

Hibernate was specifically designed to work for very complex data models.

Note that Tate has been saying this kind of stuff for years now, apparently without ever bothering to re-evaluate as Hibernate grew more and more sophisticated, and usually without bothering to provide any kind of evidence to back up his statements. (If he actually offers any technical arguments in the new book, please let us know, are so we can debunk them right here.)

So, a while ago, I sent Bruce a polite private email asking for his reasoning why - despite all practical experience of big companies we have as customers - Hibernate could not be used for "enterprise" problems. He sent me back an incredibly weak list of reasons (all HB2-specific) and then when I tried to (politely, and technically) argue his points, he got angry and threatened to write bad articles about Hibernate if I didn't show him "respect" like other persistence vendors do (???). It was truly one of the most bizarre reactions I have ever recieved to any email I have ever sent.

Basically, what I got from this interaction was Bruce doesn't like having his ideas challenged, doesn't know much about Hibernate, and isn't particularly curious. It's always annoying to have guys like this out there painting themselves as experts, but I'm afraid it is something we'll just have to live with.

Again, if anyone has actual technical reasons / practical experience of Hibernate not working in a large-scale app (ie. due purely to the scale), I am very, very interested and happy to discuss them here in this thread.

So far I am yet to hear of a single example of where someone was successfully using Hibernate on a small scale and was then unable to "grow". If there are any examples of this, we would like to heard about them. This is the only way we will improve.

What I'm hearing from enterprise customers over the last few months is basically that we have OLTP licked, and the problems are all affecting non-OLTP cases, especially batch processing. Hence, this is the focus of 3.1.

One question for Gavin and Christian : How long start Hibernate with 1000K tables ?

regards

Too long?

and link about surrogate via natural keys :

http://www.dmreview.com/article_sub.cfm?articleId=6136

I think that hibernate have to support composite id , good - all database vendors support it without special requests and all depend about database design (or designer)

I think that last versions hibernate do it good - we need composite id without special class for annotations, only

regards

I play with hibernate and I have about 20 tables - hibernate start about 30 s (pentium 933MHz,
512 mb ) - I would like to know what if I have about 300 tables (my projects without hibernate)

regards

My current project has 27 tables, Hibernate startup takes about 5 seconds. In keeping with that, I estimate the startup time for '1000K' tables to be about two days :)

This is completely subjective. It depends on two things: how much XML there is to parse and how many proxies have to be generated. Read the developer mailing list archives, there have been quite a few long discussions about it and it has been optimized already. Obviously one of the issues won't be there anymore with annotations.

1000k?

As in 1 000 000 tables?

I don't think anyone has 1 million table data models.