I know it is rather heated question. But anyway I'd like to hear opinions of those in Stackoverflow. Given that XML support is quite good in SQL Server 2005/2008, and there's no concern about database independency, why one need Linq-to-SQL, Entity Framework, NHibernate and the likes, which are quite complex and awkward in advanced use-cases, if by using POCOs, XmlSerializer, and stored procedures which process XML, one can achieve a lot less complex middle-tier? For reference, see the link: http://weblogs.asp.net/jezell/archive/2007/04/13/who-needs-orm-i-ve-got-sql-2005.aspx
A:
XmlSerialization and XML columns in databases can be difficult to work with, but I'm sure you can make it work. You'll still have to overcome standard ORM challenges like circular references. SQL queries can be quite awkward against XML database columns.
I would argue it is not ORMs that are complex in advanced use cases, it's the object-relational mismatch that is complex in advanced use cases. I don't see how XML and stored produces really addresses those advanced use cases in a better way.
XML is not relational or object-oriented in nature and you are adding an additional mismatch to the mix.
Michael Maddox
2010-06-18 09:25:43
Thank you Michael. While it is possible to have XML columns, I'm talking here about ordinary int, varchar etc. columns. With 'FOR XML' statement I can easily create xml in a stored procedure and send to client. And via ADO.NET command I can also easily send xml to stored procedure. Once in a stored procedure I have full flexibility whatever I want to do with that coming xml, like building my own logic of concurrency handling. But if you use ORM, I feel, you probably will have to deal with a lot of generated/bloated code and in the end may not be able to do what you exaclty want.
synergetic
2010-06-19 06:22:11
@synergetic: It sounds like you are adding XML to objects and relational tables and in effect you now have another impedance mismatch. ORMs, in general, don't require "generated" code and you may want to spend more time with quality ORMs before dismissing them so readily. Having business logic split between code and stored procedures is something most developers try to avoid.
Michael Maddox
2010-06-19 09:08:58
Thank you Michael. What ORM do you use? Can you recommend me one?
synergetic
2010-06-21 00:15:22
@synergetic: http://stackoverflow.com/questions/1377236/nhibernate-entity-framework-active-records-or-linq2sql/1378028#1378028
Michael Maddox
2010-06-21 09:29:29
+2
A:
The "less complex middle tier" is what worries me... the point of the ORM is to ensure that most of the complexity relates to your actual domain (whether that is order-processing, feed-reading, or whatever). That complexity has to go somewhere. And the last place you want that complexity is in the DB - your least scalable commodity (you generally scale the db server up (which is expensive), where-as you scale the app-servers out (much cheaper)).
There may be a case for using document databases instead of relational databases, but RDBMS are not going anywhere. Generally I would suggest: limit your xml usage at the db to sensible amounts. It can be a very effective tool - but be careful you aren't creating an inner-platform. The relational database (by whichever vendor) is exceptional at its job, with sophisticated indexing, ACID, referential integrity etc... leverage that power.
Marc Gravell
2010-06-18 21:21:08
Thank you Marc. It seems to me XML is really attractive option for CRUD applications. All domain data eventually lands in a database, and their complex interrelations are too. So, why not place database intensive tasks such as concurrency management at db level instead of relying on ORM's change management?
synergetic
2010-06-21 00:13:27
@synergetic - well, concurrency isn't necessarily the most database intensive thing going on. Many systems are read-intensive. Here, optimistic-concurrency may have significantly *less* cost, yet still provide all the safety.
Marc Gravell
2010-06-21 10:31:38