[dba-SQLServer] XLINQ: A Solution for No Problem, or a Doonboggle?

Arthur Fuller artful at rogers.com
Thu Feb 9 20:51:41 CST 2006


AFAIK this is a layer to pacify the VB.NET developers who cannot handle
T-SQL. IT is NOT NOT NOT intended to replace T-SQL! It is for those oddball
situations where you must declare a recordset and then do some bizarre and
kinky things within it. Do NOT NOT NOT attempt to replace your current
working sprocs/udfs/views with .NET code. That was not MS's intention and
they say so. The addition of .NET language(s) to SQL is intended for bizarre
situations, NOT standard situations.
The overhead-hit is significant, as you could demonstrate to yourself with
any number of easily written tests. I have attended a number of seminars on
this topic, and the standard opinion is "Don't go there unless you need to."
Maybe if all your tables contain fewer than 50K rows, you could go there
without noticing a performance penalty. But realize that you are building
scalability OUT of your database in going there.
The XLINQ language, IMO, is for people VB.NET developers who can't handle
T-SQL. Admittedly, it brings some new tricks to the party. And that is
exactly how you should view it, IMO. Above all DO NOT think about replacing
T-SQL that works with XLINQ! Regard XLINQ as a tool to do only those things
that are particularly a hassle in T-SQL.
Do not take this as a statement that T-SQL is the finest language ever
invented. It most certainly is not. But it will do what you need to do very
often, and the difference in performance between solution A written in T-SQL
and solution B written in XLINQ is dramatic.
At this point, the best you can say about XLINQ is that it works. You pay a
serious price for using it, however.
I view it as a marketing ploy that attempts to reduce relating to SQL Server
to a non-problem. It may appeal to university students and other newbies to
SQL, but it will not work in the trenches of serious development. The
performance hit is excruciating, unless perhaps you have MAJOR hardware. You
can even compare the performance on such a tiny db as AdventureWorks - which
we must all agree is a tiny database. Even there the difference is obvious:
you don't need tools to measure seconds -- just open your eyes and watch.
Arthur




More information about the dba-SQLServer mailing list