|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Monday, August 17, 2009 4:03 AM
Points: 42,
Visits: 138
|
|
Hi,
I need to know the difference between LinQ and NHibernate in the following characterstics:
a. Speed for insert/update/select/delete b. Database support (Like MySQL, Oracle, etc.,) (I know that:SQL joins hand with both) c. Performance with heavy datas. d. Others
Thanks
"I Love Walking In The Rain So No One Can See Me Crying ! " ~ Charlie Chaplin
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, November 17, 2009 8:32 PM
Points: 6,799,
Visits: 13,363
|
|
I don't have all the answers to your question, but I can advise you to look in a slightly different direction. LINQ is being swallowed up the Entity Framework. That's what you should be looking into and comparing to nHibernate.
I have a little experience with both. The one main difference between them is that EntityFramework is a bit more database focused and nHibernate is a bit more object focused. That made a difference for our local development team.
---------------------------------------------------- "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt The Scary DBA Author of SQL Server 2008 Query Performance Tuning Distilled
For better & quicker help read: How to Post Performance Problems
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Monday, August 17, 2009 4:03 AM
Points: 42,
Visits: 138
|
|
Thanks. But could you be more precise?
"I Love Walking In The Rain So No One Can See Me Crying ! " ~ Charlie Chaplin
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, November 17, 2009 8:32 PM
Points: 6,799,
Visits: 13,363
|
|
Entity Framework assumes a data model in the database and works with it to map between the data model and your object model. nHibernate can work that way, but our developers liked the fact that nHibernate can simply override the data model and write the object model straight down to the database. I have some serious reservations as to whether this is going to work well over time, and we're still too early in development to do serious testing with the code, so we'll see.
---------------------------------------------------- "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt The Scary DBA Author of SQL Server 2008 Query Performance Tuning Distilled
For better & quicker help read: How to Post Performance Problems
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Yesterday @ 6:26 AM
Points: 145,
Visits: 328
|
|
I hate hibernate, well, if cursor mode is used. But we tried direct and started getting some locking issues (developers didn't code for it), so went back to cursor mode where it does wrap everything into transactions. We also had extreme Jave memory pressure with direct (I think they load all three LDAP databaes of the user info into memory resulting into 2 gigs of Jave memory used). Cursors are slow as molasses with it. Countless times we've tried to find where the performance problems were. All too often I found over 500,000 requests were sent to the server for some simple queries and updates. Many of them were "If @@trancount > 0 commit tran" and this was after a select had been run. Go figure. I also get sort warnings in the form of low memory.
Never heard of Linq.
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Tuesday, November 17, 2009 8:32 PM
Points: 6,799,
Visits: 13,363
|
|
Again, I'm just getting started supporting it. However, I found some fun stuff in nHibernate that is going to seriously impact our performance over time. For example, check out my blog post on how it handles variables when passed to parameterized queries.
---------------------------------------------------- "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt The Scary DBA Author of SQL Server 2008 Query Performance Tuning Distilled
For better & quicker help read: How to Post Performance Problems
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Yesterday @ 8:14 PM
Points: 2,655,
Visits: 10,909
|
|
LINQ which is math in .NET objects still exists what is being replaced by Entity Framework is LINQ to SQL which is a mistake because what is the issue is not LINQ to SQL but rather the SQL metal that converts a whole database to classes and properties. The reason LINQ did not implement needed algebraic functions so the mapping to SQL Server needed room to use existing SQL solutions as needed something not feasible with SQL metal.
LINQ to SQL cannot be compared to Nhibernate because it claims to use one code base for all RDBMS which means a lot of the relational model of an application will be generic and not optimized for each RDBMS. One example is OUTER JOIN it is not practical to use the same code for even all versions of SQL Server from 7.0 so to use the same code for all RDBMS is not good implementation. These reasonings comes from people who thinks RDBMS is storage, may be correct in Winform application but will kill your web application.
Kind regards, Gift Peddie
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Wednesday, July 01, 2009 1:44 PM
Points: 274,
Visits: 154
|
|
LINQ is good for querying objects cached in memory. I don't know that I would use it for something other than that.
nHibernate isn't really good for much in my opinion. You are better off designing your own ORM. nHibernate has little support for stored procedures. It loads a lot more data in memory than is necessary. There were also a lot of deadlocking issues encountered with nHibernate at a company where I had worked as well. There is a big difference between a VLDB and persistent storage. nHibernate only works well in the latter scenario.
Karen Gayda MCP, MCSD, MCDBA
gaydaware.com
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Saturday, November 07, 2009 3:44 AM
Points: 1,
Visits: 0
|
|
|
|
|
|
SSCommitted
      
Group: General Forum Members
Last Login: Today @ 2:53 AM
Points: 1,966,
Visits: 3,361
|
|
Hi
As previously stated, it's hard to compare LINQ2SQL and NHibernate but give me a try 
From client development side L2S is a active-record business layer design - what means a 1:1 table to objects and columns to properties mapping. This is nice for small projects and gives the possibility to quickly start to implement the customer requirements. There is no real support for other DBMS than SQL Server. By searching the web you might find some implementations for MySQL or PostgreSQL, but no supported and maintained version.
NHiberhate (NH) supports a domain object business layer design - what means it can abstract the database structure from the client object model. The general gain of this abstraction is, you can optimize both sides without touching the other one. The pain of NH is to create the mapping XML files. Also the client side performance is way slower than L2S (or EF). NH supports all common databases.
As brought up by Grant. Don't forget Entity Framework. It is the new O/R-Mapper provided by Microsoft since Framework 3.5 (SP1). The first version (as every first version - in my opinion ) wasn't really done - as MS stated on PDC (2009?). One problem was the missing persistence ignorance, what means all objects need to derive from a EF base object. EF v2, shipped with Visual Studio 2010, fixed this problem and it becomes more like NH. EF v1 supports many common DBMSs, I don't know if there are new DBMS supported in v2.
From database side L2S is very optimized to SQL Server. AFAK the generated statements are way better than EF and NH.
NH SQL can be fine if you completely define the mapping XML, containing all column data types and data length.
EF SQL was not the best in v1. For v2 MS added some of the L2S guys to the EF team to optimize the statements. As they promise on their blog (Entity Framework Design) and on PDC it will be better in v2.
My personal suggestion If you can choose, use EF - even in v1. If persistence ignorance is not a must have for your project start you should be on the right direction. Why? Nobody knows what will happen to L2S and many people call it dead, since MS currently has two different O/R-Mapper which are way too close to live side by side. NHibernate is currently state of the art with the most features but Microsoft just started with EF and they really push it. They even intend to add EF support to the next version of SSRS. I believe v2 will be really nice and v3 will become a feature monster like SS2k8 DBMS.
Greets Flo
The more I learn, the more I know what I do not know How to Post Data/Code to get the best Help"Numbers" or "Tally" Table How to Post Performance Problems
|
|
|
|