Sorry to appear after a blog drought with theory meta-type blog entries. Too much time at conferences pondering technologies, I guess.
The "relational database bigots" I hang out with don't like LINQ at all. They hope it would shrivel up in a corner and become part of the fad-technology graveyard. Or they're waiting to make big bucks fixing the performance problems they think will ensue.
For the life of me I can't figure out why. I think they're reacting to LINQ to SQL and Entity Framework, layers on top of relational data access that happen to use LINQ to obtain sets of data. Every layer of abstraction is going to make it easier to write less-performant SQL. Granted. But think of it a different way….
You, my SQL-centric friends, have spent much of your career specializing in this declarative query language. SQL. The best language so far (modulo C.J. Date's third manifesto "D" language) to query the relational data structures at the center of your universe. LINQ is just "SQL for the rest of us(them)". Disguising iterators, everyone is now using SQL (well, at least the SELECT…FROM…WHERE…GROUP BY…ORDER BY part) to query everything and anything. You were right to invest such effort into this query language. With LINQ, it's become universal.
The impression I get (I could be wrong) is that LINQ might become the next OLE DB. OLE DB was supposed to go beyond relational data sources to provide extensions to the column-row paradigm and provide "data access" over non-relational systems like "file system" (OLE DB provider for WebDav), Active Directory, Search Server (fulltext search worked through OLE DB once), Exchange, etc, etc. (Mostly) similar access to every source of data. You wouldn't believe what data sources folks wrote OLE DB providers for in the good-ol days. Anything that could be cast to an API that could implement (or be cast to an implementation of) the Connection/Session/Command/Rowset co-types (or even just IRowset) was fair game.
LINQ is a system that provides a *SQL-like* (high-level) language for anything (including collections of objects/.NET types, XML, etc, etc). Anything that has any API that can implement IQueryable/IUpdateable. Yes, LINQ to SQL (or LINQ to Entities) doesn't always generate exactly the most optimal SQL that generates the best query plans. NO argument. But T-SQL/PL-SQL/etc doesn't always generate the most optimal query plans for the storage engine 100% of the time either. Although they will get closer than LINQ-to-database, because they (T-SQL, etc) are more tightly coupled to the relational model and query optimizer than LINQ to SQL is. Every level of abstraction (translation) pays a performance penalty; the goal is to minimize it, while making the abstraction similar. And all of the same kinds of providers that speak the LINQ language are appearing. Just like the OLE DB providers did.
So perhaps, the next version of SQL Server will support not only OLE DB-based Linked Servers, but also "LINQ-ed" servers (bad pun intended) as non-SQL Server rowset sources. Hmmm…
7 thoughts on “Is LINQ the next OLE DB? “LINQ-ed” Server as a rowset source?”
It is not L2S officially a project being replaced by EF?
Dear Bob,
From what I have heard and read about EF so far, it seems to me that (Full Scale, not only DAL wrapper) EF was more oriented towards "bear" databases, where the table structure is known, but making changes in the back end such as adding views or SPs is either too much bureaucracy, or outright impossible (due to vendor restriction). In that case, EF grants the developers some freedom by allowing them to build their own world, where they can supplement the back end with any feature at their own discretion.
Under those circumstances, the additional freedom one gains may outweigh the risks of possibly sending less-than-optimal query. In other words, EF here is actually a productivity boost.
Compare this situation with one where an LOB application is being developed by a single team, consisiting of developers and dbas. The design process starts by laying out the ER diagram, then building the tables, then adding views and SPs. The whole conceptual model is built in the back end with the full understanding by everyone. Also, since most of the logic is data centric, it makes sense to have it near the data. When a change is called for, it can be easily incorporated in the "bull" database. In such a case, all the advantage arguments that you find mentioned by sites and articles about EF become really moot. There is no obvious justification for repeating the logical model in a different layer, with the resulting additional maintenance overhead.
Surely, if the application’s logic is not heavily data centric, or if it relies on reasonably-sized data that can be safely cashed in memory, (e.g., games or simulators or an e-Trading application), then the database can be viewed as a mere persistent storage. In that case, moving the conceptual model to the front end (using EF) allows the developer to leverage much of the OOP techniques and tools without imposing a performance hit from the extra round trips to the database.
The problem with these technologies is when teams think they can be used to shortcut the design process, that somehow LINQ (or NHibernate, etc.) mean the database tier can be installed and "forgotten", and that everything will work without any effort. It is a common pattern, when all the design and tuning effort is attempted in the application only, and the end result is a poorly performing mess, with a data layer that does not support the application well, nor the other areas it will _always_ need to support, such as reporting.
As a DBA, I have no direct issues with ORM technologies, only the shortcuts that "Architects" use in misinformed attempts to avoid necessary effort.
Hi Bob,
I think half the problem is that when people talk about LINQ, they seems to use the word interchangeably with LINQ to SQL. LINQ as a language extension is quite excellent. The only thing I find odd about it is the use of SQL keywords. I would have expected more object-like keywords.
On the other hand, given where it came from, its limitations (mostly in terms of the poor object models it leads to) and the team that has now begrudgingly adopted it, I can’t see LINQ to SQL having much of a future.
LINQ to Entities (via the Entity Framework) is another matter entirely. I suspect it has a substantial future (even though the queries it generates are even less optimal than LINQ to SQL).
Regards,
Greg
An interesting read. There’s been far to few intelligent articles written about this subject by those who understand their left join from their right one. Most of what I’ve read on this subject from sql’ers shows their breath of knowledge is a table wide and a record deep. When sql experts take the measure of something it seems not to involve thinking, instead it literally means measuring it. This explains the easy sacrifice of anything that does not pass muster from their high priest – performance (It’s not really performance, it’s just the faster factor). There’s no evidence that most sql experts understand what the Linq to sql/EF is, what it’s attempting to do nor what was the motivation behind it. There’s no performance counter for motivation which flies in the face of the sql dictum: I measure therefore I am:) It’s a great irony that sqland mocks contemporary computer science. For those that live in the variable-less table world of sql to throw stones is itself silly. But the real irony is that MS has been mocking the relationaland of sql. What’s left of what is, or at least thought to be,
relational is now pushed to the end of the totem pole – a repository better known at MS as "relational storage". Sql’er don’t seem to realize that MS has abandoned modeling business problems in a relational framework. How many sql experts recognize the name Peter Chen. The object model, embodied in Linq to sql/EF, is now the future direction of MS. And this includes sql server:) And where is the sql community while all this is going on? Why there out with there table measures. While Nero fiddles Rome burns. One wonders what they are going to do if they ever wake up and smell the coffee MS is brewing for them:)
For more from the relational perspective of the MS object model see:
Linq to Sql: the ‘what’ and ‘why’ of it
http://beyondsql.blogspot.com/2008/11/linq-to-sql-what-and-why-of-it.html
Linq to Sql vs. older 4GL attempts
http://beyondsql.blogspot.com/2008/11/linq-to-sql-vs-older-4gl-attempts.html
Linq to Sql should be important to sql users
http://beyondsql.blogspot.com/2008/11/linq-to-sql-should-be-important-to-sql.html
Linq to Sql as an opportunity to sql users
http://beyondsql.blogspot.com/2008/11/linq-to-sql-as-opportunity-to-sql-users.html
Reply to comments,
AFAIK, LINQ to SQL is not being replaced, just not being as such developed. Eventually, it may be completed phased out for EF, but its still supported.
But there is a LINQ to EF too, and, in this post, I was talking about "LINQ" in general, not just LINQ to SQL.
RE: The impression I get (I could be wrong) is that LINQ might become the next OLE DB.
Something has must be done since almost no current product consume ADO.net providers. Visual Studio just lately got full schema support for ADO.net providers and Excel, statistic packages, database software ect only support the (old?) OLEDB and ODBC connections. Managed code is great at interoperating with managed code but not with the more prevalent unmanaged products. If more products would support this then I would be happy to change once again (to linq provider from odbc->oledb->ado.net) since I have lost end-user interop by switching to managed code.
Has anyone made a generic OLEDB wrapper provider for an ADO.Net provider?
I have been postponing writing by own due to disbelief that I cannot find someone else’s implementation.
Should I be worried that this does not already exist (TMK) or am I missing something?
—
Some ideas in LINQ (especially the standardization & provider abstraction) are really nice but schema issues and even edit-and-continue in Visual Studio really need to addressed. Developers in my shop seem to like looping and more procedural logic.
Comments are closed.