I'm contending with a consultant that is making some rather bold statements about Hibernate and the hbm2dll tool in particular. I want to get some community feedback in response to some of his statements. I've quoted some of the juiciest comments with my initial responses following.
Quote:
The problem noted in the use of Hibernate is not the selection of the tool for the architecture. Rather, in its use to auto-generate an underlying MySQL 5.0 database from the “top-down”. While Hibernate does provide for this kind of action, in actual practice, it is not an advisable use of these capabilities.”
The tool in question is the hbm2dll tool. The authors of Hibernate and the book, “Hibernate in Action”, Christian Bauer and Gavin King, have this to say on the subject, “[It] uses the Hibernate mapping metadata to generate a database schema that should conform with the expectations of any DBA.” (“Hibernate In Action”, p. 358) In modern development environments, using tools to generate code, schemas, etc. is considered good practice. It significantly decreases the amount of manual labor involved in development tasks which decreases the time to market for applications and makes them more flexible, robust and less error-prone.
Quote:
the resulting architecture is no better than the abstracted design laid out by the developer.
Yes, it is true that if you have a bad object model for your domain you will get a poor database schema. I'm not sure how you could expect to have a good, clean database schema generated if what you put in is a jumbled mess to begin with. If you have a poor object model you have bigger problems.
Quote:
More often than not, the resulting database is generally poorly designed (when compared to databases prepared by skilled database engineers), inadequately optimized, and requires additional effort and re-engineering to bring it back to an acceptable operational level.
This is one that I'm not entirely sure how to respond to. My impluse is to say that "poorly designed" and "inadequately optimized" are very subjective qualities and depend on the task at hand. Of course, Hibernate isn't going to generate the exact same schema that a DBA will in every case, but some of the time it will be as well optimized as doing it by hand, but at least most of the time it will be adequate. There is a tradeoff you need to make, you can spend $100k on a DBA to generate the most perfect schema imaginable, or you can go with something that works and use the money to hire another developer to work on making the system in question more feature rich. If you begin to experience bottlenecks later in development and you pin it down to your DB interactions then you can contract a DBA to perform some optimizations. But it will not required an inordinate amount of errort or re-engineering to do that as Hibernate is very good about allowing you to tweak specific queries for maximum optimization.
Quote:
For this reason, most advanced Java developers steer away from this particular functionality in favor of traditional data design methodologies. Hibernate is often still favored, but in this case it inherits the data properties from the “bottom-up” with the quality of the data schema ensured
This is exactly the opposite of my understanding of how Hibernate is used. Most developers (advanced or otherwise) use it to speed up development time and rapidly adapt to changing requirements. They use it specifically to get away from having to hand craft all their SQL statements, including the DDL statements. This top-down approach results in the aforementioned decrease in the time to market and cost of development and increases the flexibility and robustness of the system while making it less buggy. As I understand it, the bottom-up approach is usually used with Hibernate only when there is an existing legacy database that you're trying to map.
That's it. I'd appreciate it if you'd all let me know what you think, both about the consultants statements and my own.
Thanks,
Rich
Login
FAQ
Search
