IMHO part of the reason why Hibernate has so much mindshare is because it's pointy-clicky for simpler databases, which is what sells it. It sounds like Hibernate has some issues with large enterprise systems, but by then the manager/architect is already sold on it and development time is invested in it. Looking at HSQL, it doesn't seem to be that much different/easier than SQL either, except that there is a level of abstraction and one doesn't have to worry about the SELECT clause.
-ed On 7/29/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > ...and "performance is not an issue" as well as "the database will only be > used by one application". > > Larry > > > On 7/29/05, Ed Griebel <[EMAIL PROTECTED]> wrote: > > Don't forget to add to the top, "You don't use stored procedures". > > > > I haven't actually used it, but according to the docs for 3.0 version, > > Hibernate's support for SPs is weak, e.g., the stored procedure MUST > > return a result set for Hibernate to be able to use it (and that's all > > that it will use), and you have to do the configuration manually for > > it, no auto-generated config. Also, the documentation is unclear if > > you can pass record sets (or primitives even) as OUT params. > > > > -ed > > > > On 7/29/05, Jeff Butler <[EMAIL PROTECTED]> wrote: > > > When I was trying to decide on iBATIS vs. Hibernate for my current > > > project, it came down to this: Our DBAs require that all SQL sent to > > > production databases be reviewed/analyzed/tuned before being placed into > > > production. This forced us into "human written SQL" I think this is > > > not an uncommon requirement in any kind of reasonably sized system. > > > > > > We also have a domain model that is far different from our DB model - > > > that alone may have pushed me in the iBATIS direction. > > > > > > Maybe we should publish some kind of "Is iBATIS Right for My Project" > > > decision tree. I think it would look like this: > > > > > > If Your data store is a relational database > > > && You are not trying to reuse an existing database designed for > > > other applications > > > && Your domain model is a reasonably close match to your DB model > > > && Your developers have good control over DB design without DBA > > > "enhancements" > > > && Your DBAs do not require SQL reviews > > > && Your developers are weak with SQL > > > Then some kind of ORM tool (Hibernate, OJB, JDO, EJB3, etc.) could > > > possibly be right for you > > > Else - iBATIS is probably a better choice > > > > > > Not that I'm biased or anything :) > > > > > > Jeff Butler > > > > > > > > > >
