Hey fellows, IMHO, HQL is simply stupid. What is the goal of Hibernate? Allow me to use objects instead of SQL statements, etc. So, why the heck do i need to learn a new query language? If Hibernate goal is to make my life easier, learning a new language (even being very similar to a known one) isn't going to make it! I already have to know a lot of languages (C/C++, PHP, Java, Pascal, Python, SQL, PL/SQL, VB, etc). And learn a new one just to do what an old one can? Come on!
And, on the other hand, if you work on a large corporation, developers having control over DB is a dream! Specially with Oracle, Sybase and DB2 plants (i won't include MS SQL Server on this list, because, it is too 'clicky'). DBAs _are_ necessary, because we already have too much things to worry about. And, having a large experience with databases (Oracle the more), i'd say DBAs are essential! And good DBAs won't allow you to run any crappy SQL without a thorough review. That's their job. Or you could end up with cartesian products of tables holding some million records. And you scratch your head and think: "Dang, what is going on here with this database? It is so slow. Hey, someone call Oracle support!" My 2 rants, err... cents ;-) Cheers, Daniel Silva. On 7/29/05, Ed Griebel <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > > > > > > > > >
