Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Andraax
Aged Yak Warrior
790 Posts |
 Posted - 2007-02-08 : 06:33:39
|
| Hey guys, long time...We have an ongoing discussion here at my company about using an O/R mapper called Hibernate, to simplify application development above all for our application programmers who use Java (J2EE). This would be constrained to quite simple operations such as persisting application data.Using Hibernate involves mapping an object model to the data model, and then hibernate takes care of creating the SQL statements for select/update/insert/delete operations. I'm trying to be objective and open-minded, but I would rather see that we use stored procedures for those operations. My arguments so far are:1) Using hibernate would demand that the object model and data model are quite similar, which is not always the case.2) Using hibernate would make it harder for us to control what gets into the database, we would be restricted to constraints for making sure the "right stuff" gets into the database. 3) As a database developer/DBA, I won't be able to take the same responsibility for the quality of the data or the performance of the database.4) Every architect talks about hiding the internal structure of each layer of an application, and hibernate would not support that.Of course, our developers have basically the following arguments:1) Less development time for both Java developers and database developers (only a data model with tables required, no procedures etc).So, do you guys have any input on this? Or maybe even experience?/Andraax |
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2007-02-08 : 09:30:15
|
| I presume your developers are also counting the cost of "poor quality performing" SQL code and also the cost of support when things go wrong....just because it's faster to code in VB compared to Assembler, doesn't mean VB automatically is the best solution for all cases. Sometimes the other non-obvious costs have to be factored into the equation. And the arguement goes into reverse for the 2 stated languages as well on the performance level.....horses for courses.Developers always look to make development easier...good developers will look to make all aspects of solution delivery easier...not just the development stagesOf course if Hibernate leaves security gaps or migration problems down the line, then ease of development will be moot.... |
 |
|
|
peterlemonjello
Yak Posting Veteran
53 Posts |
Posted - 2007-02-08 : 10:07:07
|
| We use Hibernate and NHibernate. They're both good products if implemented correctly. IMHO the two things that make Hibernate worth using is lazy loading and the 2nd level cache. Basically, if you're not going to take advantage these two features don't use Hibernate.1) Hibernate doesn't require the object model and data model to be similiar. You can use views and custom sql in Hibernate mapping files to handle major difference between the object model and data model.2) This is true but wouldn't you do the same thing if you used stored procs?3) Actually you still should. You'll just have to work more closely with the development team to achieve this.4) This can be debated.Last Item) Hibernate has a steep learning curve. It sounds very simple but there are a lot of gotcha's if it's not implemented correctly. I don't think it speeds up development. Honestly it just moves some of the development from the dba group to the programmers. You end up writing more java code and xml instead of TSQL.Andrew mentioned migration problems. I just worked on a project using Hibernate that was migrated from SQL Server to Oracle. Thanks to Hibernate the migration was very simple since Hibernate abstracted the data access layer from the db vendor.Edit: I'd like to mention in most of our projects we still use procs when needed for performance. Any reports and most read-only data is retrieved using procs. We only use Hibernate for OLTP objects. |
|
|
|
Andraax
Aged Yak Warrior
790 Posts |
Posted - 2007-02-09 : 06:48:10
|
| Thanks for your replies!Some answers to Peter:1) OK. I though myself of making views and (instead of) triggers to handle different object and data models, but it feels like there will be more work for both DBA and java developers if we do that.2) Sure I would, but everything cannot be accomplished with constraints.3) Yeah, but it still means I cannot take the same responsibility on my group, since we don't have control of what actually gets run.4) An example: Let's say that we build this database with a data model which in large corresponds to the object model of the current project, and use Hibernate to access the data. Next, a new project starts which wants to reuse the same data, but make some small modifications, additions etc. We will get a change of the data model resulting in a possible change of the first project's application code. Now, let's say after a while the first project wants to change the way a certain part of the data model works. This will cause the second project to rewrite some of their code, and requires that both projects release a new version simultaneously. Now imagine this with 10 projects instead of 2.I've read up on this and I think that 4) is so far the most important reason not to use Hibernate, except in simple/small projects/systems where I think it can be great.Also, I read this excellent blog conversation with Adam Machanic etc. [url]http://sqlblog.com/blogs/adam_machanic/archive/2006/07/12/no-stored-procedures-are-not-bad.aspx[/url] |
|
|
|
peterlemonjello
Yak Posting Veteran
53 Posts |
Posted - 2007-02-09 : 09:24:39
|
| You bring up some very good concerns Andraax. For me item 4 is huge. This can be a nightmare to manage no matter what solution you choose. If this is the scenario you're going to be stuck in I'd recommend choosing a solution everyone is familiar and experienced with. If the developers have never used Hibernate you're definitely adding more risk to the project that you wouldn't have otherwise. Don't get me wrong. In this scenario both solutions have advantages and disadvantages over the other. Not to mention both solutions will work. Personally, I'm still undecided whether I prefer ORM tools over procs. In my first reply I mentioned Lazy-Loading and Hibernate's 2nd level cache. In my role as a developer and dba I recognize these two things are very powerful. IMHO, from a pure technical perspective, these two things are the biggest benefits Hibernate provides over using procs. If your applications won't benefit from these two features I probably would never consider using Hibernate. |
|
|
|
rockmoose
SQL Natt Alfen
3279 Posts |
Posted - 2007-02-09 : 15:21:51
|
| I tend to think in interfaces.Program to interfaces, change an interface and code will break.imo ORM tools see the physical database model as the interface to the database, with some tweaking and views etc..But what I prefer form an architectural perspective is to provide database interfaces in the form of stored procedures.This provides much better encapsulation of the physical database model, and it CAN change without breaking the interfaces to the db.rockmoose |
|
|
|
|
|
|
|
|
Hibernate?