x

Is SQL on the way out?

Ok, so I will be the first to admit that, in language definition terms, SQL is horrible. Having written a code completion engine for it, I think I can say in a reasonably qualified form that the language specification leaves a lot to be desired. Lexing is OK (despite a few weird rules) but Parsing SQL is really hard.

So along comes LINQ. For all the language definition reasons, it's way ahead, as it would be, it's a much newer language.

But I have to say, I just don't like it. While the language definition is much better, I don't think that it reads nearly as well. Sure, for a simple 'let's get one row back from the DB' then it's perfectly understandable - but I would imagine that most people here tend to do a lot more than that while generating reports etc.

The other thing that scares me about it is the 'trendiness' factor. It's like you get kudos for using LINQ in whatever situation in some circles - and, in my experience, that has always lead a good technology to become a 'band-aid' solution which is used everywhere, no matter how inappropriate. Given how much I've learned about query optimisation through participation here (and being more of a 'lurker' on the main SSC site) I don't want the opportunity to exercise that knowledge to disappear - because, for the main part, efficient queries come from really understanding the data at hand, and I don't think it's possible for LINQ to have that level of understanding.

What are your thoughts? And apologies that this is a 'no-correct-answer' sort of question, accept for highest voted answer in 7 days...

more ▼

asked Jan 29 '10 at 06:09 AM in Default

Matt Whitfield gravatar image

Matt Whitfield ♦♦
29.4k 61 65 87

(comments are locked)
10|1200 characters needed characters left

11 answers: sort voted first

No.

Oh you want some elaboration.....

For so many reasons, like Håkan mentions, SQL will not succumb to LINQ, or any ORM.

I'm not saying SQL won't change, but the fundamentals seem so firmly based and have stood the test of time, that it seems unlikely. What may change is the data model that gets used. Relational data isn't perfect by any stretch, but fits more scenarios than hierarchical data models, network data-models, eav models and whatever else has been tried over the last 30 years or so.

I accept that as a SQL professional, I am defensive about this, but to be honest every time another trendy alternative comes along, I just see it as an opportunity in-waiting, as surely a number of months/years down the line, the 'trendy' solution just can't cope and the data layer needs re-writing using good old SQL.

more ▼

answered Jan 29 '10 at 07:17 AM

Kev Riley gravatar image

Kev Riley ♦♦
50.7k 43 49 76

But SQL is not relational, so if the relational model is the best fit for data management then by implication surely SQL is not such a good fit?
Jan 29 '10 at 07:41 AM David 1
I don't think SQL's fundamentals can reasonably be described as "firmly based" when compared to the state of the art and practice. Even basic type safety is beyond SQL. So are a great many declarative data integrity rules, which frequently have to be formulated in other languages. Also, SQL's reliance on multisets and poor support for keys is one major reason for SQL's unsuitability for "OLAP" decision support applications - a defect, which costs the industry $millions through having to maintain separate data models like SSAS.
Jan 29 '10 at 07:42 AM David 1
but despite what you say (and I agree), it's still here and has been for a while - not many things in IT do that - so there must be something about it?
Jan 29 '10 at 07:55 AM Kev Riley ♦♦
There's something to be said for SQL's longevity. Over the same period that SQL has been, to all intents & purposes, unchanged, we've seen PAL, OPAL, Basic, VB, C#, Java, F#, PowerShell... tons of others, many different languages rise & fall, but SQL trudges on, irritating though that may be to the methodology-du-jour folks.
Jan 29 '10 at 10:37 AM Grant Fritchey ♦♦
(comments are locked)
10|1200 characters needed characters left

As long as we have structured data, there's going to be a need for a language to query against it. That's not to say that SQL in it's current form is the way to go, but some type of language that is capable of dealing with pulling data out of relations within structured data is needed, and so far, none of the alternatives is more workable than SQL, in fact, most are less workable. Both literally and figuratively, in terms of an alternative to SQL, I'm from Missouri... Show me.

Until I see a fully functional alternative, I'm going to stick with SQL. That means that all the problematic ORM tools are going to remain, to a small degree, a thorn in my side. They don't deal well with SQL or relationships. They are, in my opinion, an attempt to ignore SQL, not replace it or deal with it. That, unfortunately, is the worst possible approach. Better to deal with it badly than try to pretend it doesn't exist and then generate all the horrors that I've seen & heard about.

However, get me a better method of querying the database, and I'm all for it. There's no reason to be married to a language. Based on the last 60 years of computing history and my own 20 years within it, we will get a different language eventually. Languages, OS's and platforms come & go. Nothing is carved in stone. But, at this time, there's nothing viable as an alternative that I can see.

more ▼

answered Jan 29 '10 at 10:35 AM

Grant Fritchey gravatar image

Grant Fritchey ♦♦
90.9k 19 21 74

If you didn't live 4,212 miles away I'd be asking if you wanted to go down the pub and discuss what your thoughts on a better alternative might be... :)
Jan 29 '10 at 11:48 AM Matt Whitfield ♦♦
How about a D-language (such as Alphora D4) as a better alternative?
Jan 29 '10 at 12:02 PM David 1
Love to. Nothing better in the world than English beer.
Jan 29 '10 at 12:30 PM Grant Fritchey ♦♦
I'm not familiar with that one, but I'll take a look at it when I have a second or two.
Jan 29 '10 at 12:55 PM Grant Fritchey ♦♦
Let me know when you're in my neck of the woods then, sir...
Jan 29 '10 at 04:58 PM Matt Whitfield ♦♦
(comments are locked)
10|1200 characters needed characters left

I have seen so many bad SQL statements written by developers and LINQ scares the hell out of me. I am afraid that with LINQ, even more developers will think that they can develop efficient database driven applications, and ignore the need for an experienced database developer, and in the end when the developers have left the building (consultants) the database performance will slowly degrades until the system is useless.

By then, when a DBA is involved trying to optimize the code, everything is build in C#, VB.NET or whatever, leaving the DBA without any options then add more hardware.

I think for small to medium sized databases,it is possible to write crappy code and the system still works (thanks to the hardware), but when it comes to large and huge databases it is not possible to solve the issues from crappy code with more hardware. The only solution is to modify the code.

more ▼

answered Jan 29 '10 at 06:30 AM

Håkan Winther gravatar image

Håkan Winther
15.5k 33 37 48

(comments are locked)
10|1200 characters needed characters left

My first response is "no, SQL works well"

However the note by dportas is interesting. Should we be looking at a way to possibly evolve to a new language that works better? We have seen "C" evolve to C++, C#, and now F# in some ways. Python is a very interesting environment to me as well, but in spite of all the work done on languages, there's still a decent amount of C around, and I wonder how much C++ code is actually C compiled in a new IDE.

From what I've seen in terms of how we work with data, SQL works pretty well, but it has a decent learning curve and requires someone to fundamentally be able to understand how SETs interact. That feels like the pointer issues of my early career where lots of people just could not understand a pointer.

If I had to say that SQL fails in one place, and I've seen this with the intellisense challenges, is that it doesn't fundamentally order the commands correctly. In my mind we ought to decide what tables we are using first, then get columns and relationships. So something like

FROM Customers c
  Inner Join Orders o
     on c.custid = o.custid
SELECT c.customername, o.orderdate, o.ordernumber
 where o.orderdate > '1/1/10'

I think that we possibly could also find some other ways to create set interactions, or perhaps even have FKs automatically joined with a keyword, could build cleaner code. The whole change to using a CTE in SQL, with the code at the top, to me, means it's fundamentally harder to read. That was, in some sense, a step backward by bolting something on rather than fundamentally re-working the language.

I think LINQ wasn't a bad idea, but the way it translates into SQL is what I find problematic.

more ▼

answered Jan 29 '10 at 02:46 PM

Steve Jones - Editor gravatar image

Steve Jones - Editor ♦♦
5.1k 76 79 82

Oh heck yes! That syntax change alone would make a huge difference in the functional understanding of SQL. Great point.
Jan 29 '10 at 03:38 PM Grant Fritchey ♦♦
Agreed - +1... And I know about the FROM bit first - I put a mode into my engine where you type SELECT tablename. and then it changes it to SELECT schema.tablename. FROM schema.tablename - was the only way I could think of to address that one...
Jan 29 '10 at 05:01 PM Matt Whitfield ♦♦

MDX has had WITH clauses for some time now so I believe they added CTEs to SQL to create similar functionality. LINQ has the table/source first for precisely the reason you have indicated, to make intellisense work

Your last sentence is the reason Matt will not have to discard his SQL knowledge any time soon. Eg You can write sloppy C# code and it will still seem to run as fast as optimized code. You can add more layers of abstraction to a language and it will seem to perform admirably.
Jan 29 '10 at 05:06 PM Scot Hauder
The same is not true for SQL, what may seem like modest change in logic or design of a query can literally alter the execution time from seconds to tens of minutes, or even hours. To formulate optimal SQL you need to have an intimate knowledge of the data, the schema, how users use it, the db platform and a deeper understanding of your problem domain, what you want to accomplish and how to translate that solution in a way that the db can carryout efficiently. LINQ knows little of this and must work with the lowest common denominator so it can be used with disparate data sources.
Jan 29 '10 at 05:07 PM Scot Hauder
For this I am not a fan of Linq to SQL because I know my SQL knowledge can always outperform it, Linq to objects/xml is quite useful though. I think a great deal of improvement can still be made but translating what someone wants from a database into optimal SQL would be cost prohibitive and take too long to develop
Jan 29 '10 at 05:07 PM Scot Hauder
(comments are locked)
10|1200 characters needed characters left

Good question. SQL is surely a very poor platform for modern development needs. The fundamental language features of SQL DBMSs have improved very little in the last 30 years. Compare that to the major innovations in object-oriented languages over the same time period. Part of the problem is that the SQL model was fundamentally based on some flawed ideas and designed to work within the constraints of 1970s systems. The domination of the SQL DBMS market by three major corporations with vested interests in maintaining the status quo has also not helped.

I think the database management profession ought to be able to answer the question by saying "Yes, I hope so". We really ought to aspire to better things than SQL. I'm definitely not saying that LINQ is the right successor to SQL but at least it is one initiative that is showing some kind of way forward. The various products that go under the "NoSQL" banner are another example.

Unfortunately I think SQL database professionals have sometimes been a little too defensive about SQL and this has left them somewhat outside of the discussion rather than participating in it and putting forward alternatives. I think more data management professionals at the grassroots level need to recognise the need for new alternatives to SQL and contribute to the development of those future solutions. For instance, where are the relational-based alternatives to the SQL DBMS model?

more ▼

answered Jan 29 '10 at 06:55 AM

David 1 gravatar image

David 1
1.8k 1 3

Your comments are always thought-provoking... This one is no exception!
Jan 29 '10 at 11:56 AM Matt Whitfield ♦♦
A very thought provoking example, and I agree that we should be looking for something better than SQL. The problem is that nothing has emerged that is in general better than SQL. ORMs have their place, but it is currently niche. The same with the NoSQL technologies. They are certainly better for some things. But for many things right now there is no better solution than SQL and I have not yet heard of anything on the horizon that I expect will get there. I can think of some tweaks to sql I would like to see, but fundamentally I cannot come up with a better alternative myself.
Jan 30 '10 at 03:23 PM TimothyAWiseman
(comments are locked)
10|1200 characters needed characters left
Your answer
toggle preview:

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

New code box

There's a new way to format code on the site - the red speech bubble logo will automatically format T-SQL for you. The original code box is still there for XML, etc. More details here.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

SQL Server Central

Need long-form SQL discussion? SQLserverCentral.com is the place.

Topics:

x977
x107

asked: Jan 29 '10 at 06:09 AM

Seen: 2468 times

Last Updated: Jan 29 '10 at 06:09 AM