Hibernate
-
My lovely software developers want to use a tool called hibernate which is a object/relational mapping tool for a new system. Does any have any experience of this tool? and positive / negative feedback on it?
I always get nervous of things that auto generate sql for several different databases and can't see how it can fully leverage the full functionality of any of them . It generates the sql for the java methods in is own sql dialect which you can replace with native sql or stored procedures but all I can see is performance headaches and lots mumbling under my breath. So if any of you can help me out by either extoling its virtues or professing it it to be pile of something then it would be very much appreciated.
Thanks
David
-
I know that a lot of people (and one day I might give it a go) use code generators to generate a lot of the boilerplate code for insert/update/select stored procs to cut on the initial amount of coding... But I suppose this tool goes a step further as it continues to manage the objects & the mappings to SQL... I suppose that so long as you don't have to stay shackled to the tool once you have used it for the initial coding, you have nothing to lose...
But I've not worked with it so I may be way off base
-
I've not yet put it into production, but Hibernate is becoming the defacto standard in the java world for OR mapping. It's a robust tool that has matured to the point where it is very flexible. That flexibility can accomodate many peformance issues, but it does come with it's own learning curve.
-
Thanks for the replies guys.
Its just one of these things where from the software developers point of view you can defietly see the benefits i.e. no more hand coding of all data access objects but you just get a little concerned about how tighlty this binds the application to the data structure of the database i.e. If i make a change will this now break the application? Because if I use stored procedures and hand coded DAOs as long as the result set stays the same it has no effect on the application.
Anyway they've now at least agreed to test it
before commiting to using it on the new application that we are developing so i'm a lot hapier now and we'll see how it goes.Ta
David
-
Keep us up to date with how it goes - would be interesting to see the pros and cons of such an approach in "the real world"
-
Well it seems to be going well our Java bloke has happily used hibernate to map the stored procedures saving himself lots of coding effort and the data access code he is generating so far seems to be far more efficient than what had been generated by hand in the past.
I may be imaging it but it also seems that SPs in 2005 have got more of a performance advantge over adhoc sql than they did in sql server 2000 but this is just an observation on the fact that everything seems to hit the cache with very very few recomplies and no bad plans being used so I'm guessing some of the issues with auto parameterisation have been sorted out.
Anyway since hibernate seems be working well using stored procs I'm all in favour at the moment.
David
-
So you/your programmers are using Hibernate to wrap up an SP in a easier to call Java method call? Makes sense... I suppose this offers some benefits in ensuring that your DB stored procs and your Java code stays in step because once you make a change to the stored proc (eg add a parameter), the Java method's signature would change causing any code that calls that proc to not compile until the extra parameter is handled appropriately... Nice
Are you using it for object mapping and storage too?
-
My developers begin to drool when Hibernate is mentioned. Have you seen/heard of any gotchas so far? My director just handed me a book and said, "This is what we are going to. So, get reading." So, looks like I have some reading to do.
-
All,
We have developers that use hibernate to make sure that they don't have to know anything from the database. They develop with an in-memory postgress database, using a few percent of the data, code that needs to run on SQL Server. Most of the time, the database isn't even normalized. The application is chopped up in lots of different databases without foreign keys (they call it SOA). "The application takes care of foreign keys and constraints" they say. There are subtypes and fake inheritance all over the place: tables contain most NULLs and allow logical contradictions. Of course almost all columns are varchar(255) NULL allowed even when they should contain numbers, and all data is free entry for the end user. The inheritance is implemented by a varchar(255) that redundantly stores a type definition string and of course isn't selective enough for an index. Huge production machines are going down with small databases (e.g. a 16 processor machine, 32GB ram incapable of running a database of 3,5 GB). And of course as a DBA they don't allow me to do anything about their bad schema and un-optimized generated hibernate queries that are compiled in their applications. Since the developers don't see production, they don't care and management doesn't understand.
I suppose using stored procedures in their hibernate and modelling correctly would make everything ok.
But here I just wanted to share my feelings. I have been a DBA for more then 12 years and I haven't seen anything like this before.
I fear that this is becoming an industry trend. I used to believe that it was a quick and dirty solution. But it seems to take them even much more time to develop something, so it isn't quick.
regards,
Jan
-
SOA and OR tools are definitely becoming a standard. They can allow more rapid development than many other approaches, but often come with an implied promise that they can deal with all data storage issues.
For new users there is a temptation to believe the hype about data storage management, because these tools work fine with small quantities of data. People get tempted to keep the standard code layers for presentation and business logic, but allow the tool to merge the data access layer into the business logic because no steps are taken to separate it. If the final application only has a few users and a few MB of data, then response time is acceptable.
But we all know that if the data access is done using generated code to get data from generated storage structures this simply does not scale.
Some organisations get things right on the first attempt and insist on maintaining a formal data access layer, designed and managed by database profesionals, and delivered by the use of stored procedures.
Other organisations can get as far as production testing before realising the application simply will not work and has to be rebuilt using a data access layer. The lucky organisations will have the time and budget to do the rework. The unlucky ones will fold.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
EdVassie (1/13/2010)
SOA and OR tools are definitely becoming a standard. They can allow more rapid development than many other approaches, but often come with an implied promise that they can deal with all data storage issues.For new users there is a temptation to believe the hype about data storage management, because these tools work fine with small quantities of data. People get tempted to keep the standard code layers for presentation and business logic, but allow the tool to merge the data access layer into the business logic because no steps are taken to separate it. If the final application only has a few users and a few MB of data, then response time is acceptable.
But we all know that if the data access is done using generated code to get data from generated storage structures this simply does not scale.
Some organisations get things right on the first attempt and insist on maintaining a formal data access layer, designed and managed by database profesionals, and delivered by the use of stored procedures.
Other organisations can get as far as production testing before realising the application simply will not work and has to be rebuilt using a data access layer. The lucky organisations will have the time and budget to do the rework. The unlucky ones will fold.
As a database architect/developer for over 25 years (DB2, Oracle, SQL Server) I agree 100%. In most cases, when the auto-generated SQL query runs as slow as molasses, it is always the database's fault.
[font="Arial Narrow"](PHB) I think we should build an SQL database. (Dilbert) What color do you want that database? (PHB) I think mauve has the most RAM.[/font] -
And how do you get the development team to be bothered about production performance?
Simples.
You include performance criteria in the development sign-off requirements. These are often known as non-functional requirements, and can include security, DR times, etc as well as performance.
If you just target your developers to meet functional requirements, just do not be surprised if they ignore requirements they have not been told about.
If the development team knows what the NF requirements are and how they are to be measured, then they are obliged to include these in their design and in their test cases. You should then get a system that has a chance of doing what the businees needs to be done.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply