
In defence of SQL - seldo
http://seldo.com/weblog/2010/07/12/in_defence_of_sql
======
jasonkester
I've never understood why programmers don't love SQL the language. It's the
closest thing you can get to the silly voice interface they use in Sci-Fi:

"Computer, give me a list of orders for red sweaters, but skip ones from
customers who signed up more than 3 months ago"

... and it will figure out how to get you that list. And the syntax is so
simple that you can do pretty much everything you'd ever want with _six
keywords_. The query to get the list above is actually _shorter_ than its
English language description.

Whenever I see some new ORM come out with its own way of asking for records
from a database, a little question mark pops up over my head. Why would you do
that? Did you really spend time building something to make your problem
harder? Your code less elegant? Why why why?

The only thing I can imagine is that people simply don't bother to learn SQL
before deciding they don't like it. Too bad too, because writing queries is
one of the most enjoyable bits of the software development game.

~~~
sjs
Part of the attraction to ORMs is that you just define your classes and
essentially freeze-dry and thaw objects with a couple of lines of code.

[tangent] That's part of the attraction to NoSQL as well. You just serialize
your objects to JSON or something else (probably already being done if you
target the web). It's simple.

Back to ORMs, you can't avoid SQL wrappers at least to help w/ injections, and
you probably want a layer that serializes/deserializes your objects as well.
Once you've written that a few times it's boring so you abstract it. ORMs are
pretty much inevitable when writing the common web app.

ORMs should borrow good things from SQL, like LINQ. Mainstream languages are
better now than when SQL was created. I mean, it's not the exact syntax you
like right? I prefer writing code rather than preparing and parsing strings.
Plus if you ever decide to swap out the backend it's far easier when things
are loosely coupled.

SQL is akin to JS in the browser in that you need a library to abstract away
the implementation differences or you'll be tightly coupled to a specific one.
Maybe you don't need to run on all backends simultaneously but options are
always nice.

It all depends what the task is anyway though.

~~~
jasonkester
_Part of the attraction to ORMs is that you just define your classes and
essentially freeze-dry and thaw objects with a couple of lines of code._

That's not unique to ORM. We don't use an ORM at Expat, yet all our objects
still have .Load() and .Save() methods. I hope you didn't read my post to mean
I advocate hand-writing your CRUD!

I think LINQ is a great example of needlessly re-inventing something that
wasn't very hard in the first place. Especially since its syntax is so close
to SQL. Why not simply write your ad-hoc reports in SQL itself and save a lot
of trouble?

~~~
vyrotek
There's a lot of power and flexibility using a Model with LINQ. The strongly
typed nature has saved me many times. When you alter a table and remove or
rename a column you know exactly which queries are now broken at build time.
If you were generating or hardcoding sql there's a chance that you hosed a lot
of things and need to dig through all the code.

Dynamically creating queries is amazing in LINQ. Building them with strongly
typed expressions is much better than messy string concatenation.

~~~
jasonkester
Again, that's not unique to LINQ. Drop a db column in the thing we use and the
project will fail to compile until you fix up the references. And of course,
if you're keeping your stored procedures in source control and recompiling
them at build time (which of course you should), you'll know when you break
them too.

As you say, strongly typed dataobjects are pretty cool. Regardless of how they
interface with the database.

------
gfodor
I think he's got it backwards. He says SQL is a great language in front of a
crappy model, the relational model. I think SQL is simply a limited language
in front of a great model. The NoSQL folks are throwing out both, so I guess
that's "the only way to be sure." Going to be fun seeing them re-invent the
wheel for the next 5 years.

What we need is a more elegant, flexible language instead of SQL for data
retrieval. SQL++, since the relational model is sound. Beyond that, we need a
more intelligent data store that will be able to translate a fully normalized
schema into a high performance, distributed, persistent representation that is
queryable by this language.

There's no reason in theory this can't happen, its just hard. To think that
dropping us down to GET and PUT operations is the answer is just saying "we
give up."

~~~
sofuture
That's an overly simplistic framing of 'NoSQL'. Despite every piece of FUD to
the contrary, 'NoSQL' is a stupid name for a set of tools designed to solve an
entirely different set of problems.

I don't _want_ some data in a relational model. Yes, I could put it there, but
I would be doing so solely so that it fits in the relational model. Which is
pretty pointless.

The fact that the relational model is "sound" doesn't mean that everything
belongs in it. Plus, I'm not holding my breath waiting for an "intelligent
data store that will be able to translate a fully normalized schema into a
high performance, distributed, persistent representation that is queryable by
this language". That's the description a mythical database panacea that solves
all problems with no downsides.

The continual pitting of NoSQL vs SQL is a gross mis-characterization
perpetuated out of holy-war fervor, yet based on few facts or even
understanding of the differences.

~~~
gfodor
The relational model is a comprehensive, complete way of representing any form
of data. Just because the abstractions in front of the relational model make
it somewhat klunky to access, say, keys and value based data models, has
nothing to do with the mathematical soundness of the model. The limited
"models" most of these NoSQL stores provide are simply subsets or re-
projections of the relational model where the implementation basically bleeds
all the way up to the modelling abstraction of the system: they are one in the
same.

The database I described is not a panacea, you'd still have to do both good
modelling _and_ describe the ways to optimize the materialization of your
data. It doesn't make the core challenges of data architecture any simpler,
you still need a brain. It does, however, provide a clean abstraction and
would in theory maintain most of the good things that RDBMSes have brought us
without throwing all the hard work of our elders in the trash can.

~~~
mathias_10gen
If you (and everyone else who've made the same argument) substitute "Syntactic
Sugar" for "Abstraction" and "Turing Complete" for "Relational Model" I think
you've just made the claim that every application can or should be written in
Brainf*ck or one of the other Turing tarpits. Just because a model is
mathematically proven comprehensive, (I'm not 100% sure if relational is but
that doesn't matter) doesn't mean it's the most natural way to express/solve
your problem. And really, that is the only thing that matters. At least when
comparing models and not implementations.

------
jbarciauskas
This article reiterates a fundamental point that object stores quite clearly
present less friction during development than relational stores. This is
plainly true: your domain object is meant to model the domain, and if you can
store it directly that is the best you can hope for. There's a reason there's
a whole topic of study and research called "Object-relational impedence
mismatch" ([http://en.wikipedia.org/wiki/Object-
relational_impedance_mis...](http://en.wikipedia.org/wiki/Object-
relational_impedance_mismatch))

However I think ORMs are too quickly dismissed. In the simplest case, an ORM
can appear to be a key-value store at the API level. Of course that is a gross
abuse of a relational store, but there's no reason it can't be done.
Additionally, the author fails to note that an intelligent ORM can provide a
caching layer that improves performance over raw SQL. A more detailed
examination of the various patterns to resolve the impedence mismatch, such as
active record versus data mapper, ORM caching strategies, and how those
compare to a key-value store solution, I think would be a valuable topic of
discussion.

~~~
seldo
If the ORM layer is providing a caching layer on top of the RDBMS, that
caching layer is effectively a non-relational store for the data. If that
works better, why not use it as the primary store?

~~~
jbarciauskas
Not necessarily - you could store a resultset based on the query and
parameters, and if the same query and parameters come within a certain amount
of time, you return the whole resultset from the cache. In this scenario, the
resultset could contain a filtered list, aggregate functions, etc, that are
more difficult to replicate in a key-value store.

~~~
gaius
That is exactly what Oracle Coherence (nee Tangosol) does.

------
nlawalker
>> The birth of ORM lies in the fact that SQL is ugly and intimidating

I disagree. In my opinion, the birth of ORM lies in the fact that a lot of
people want to work on problems that have almost nothing to do with SQL but
need persistence. They want to spend time working with objects in their domain
model and just have persistence that works.

So if that's the case, why did ORM even appear? Why didn't everyone just spend
time figuring out "NoSQL"/key-value stores/object stores and move away from
RDBMS? 1) SQL and relational data stores, as the author himself points out,
are trustworthy and standard. People may not like working with them or be
intimidated by them, but most people can at least figure out simple joins and
things. The relational model may not be the best answer for some things, but
it at least gets the job done. 2) Just because I want to work with my domain
objects in my application, and just because I'm short-sighted and all I care
about at the moment is enabling a business idea or solving an interesting
problem with my app, doesn't mean that I won't want to "get answers" from my
data in the future. Maybe it won't be me - maybe it'll be another group in my
company with more RDBMS knowledge than I have that's interested in data-mining
my store, and because I've used an RDBMS, it will work extremely well.

I don't think developers are scared of SQL, I think they just don't care about
working with it because it doesn't have much to do with what they're interestd
in. Maybe ORM isn't a perfect solution, but it lets me have my cake
(persistence that gels with my domain model) and eat it too (a relational
backend when we need BI and reporting).

~~~
mistermann
I agree. The OP seems to fall into the camp that, if ORM can't replicate
_everything_ that you would do in native SQL, then therefore ORM is bad. Which
is absolute nonsense of course.

I just don't see how the pure SQL people and ORM people are philosophical
opponents, other than how ORM tools make dealing with SQL (which is an
awesome, proven technology) so much easier, I suppose it could theoretically
be a threat to their livelihood. The way I see it, they are partners in the
same cause.

I'm the same as you, I write applications that need to store and interact with
data. The difference between using an ORM or not is like light and day, and
for me, this constitutes 90% of my work. Certainly, there are situations where
it is just common sense to drop down to raw SQL (and if your ORM doesn't
support this, you are screwed), but people like the OP seem to subscribe to
the "throw the baby out with the bathwater" philosophy of life....if you can
find a single problem with a solution, throw the whole thing out.

This is one of those arguments that will never, ever go away. I used to be
passionate about the subject, but I don't care much anymore. The anti-ORM
people will continue to say it doesn't work (ever), while the pragmatists will
continue to use ORM because it does work, and for the edge cases, they will
drop down into pure SQL, which most developers know very intimately anyways.

On a related topic, how many DBA's have you met that understand SQL, query
plans, etc deeply, and have a strong knowledge of database system tables (as
well as you do as a developer?) Most DBA's I've met basically follow:
<http://en.wikipedia.org/wiki/Argument_from_authority>

~~~
wlievens
The reason pure SQL people and ORM proponents don't always get along is that
ORMs make it very easy to write really crappy queries. I'm fully in the ORM
camp, but it is true that I can't turn on SQL statement logging without being
terribly embarassed. And tuning and optimizing these queries isn't always as
trivial as some make it sound. For fetching some data, it's not terribly hard,
but try explaining to Hibernate that you want to bulk delete a bunch of
objects (with inheritance) without screwing up your session...

~~~
kunley
It's all about people, not the ORMs or other technical inventions.

Most shithead queries I encountered during years of DBAing were written by
hand by poor folks abandoned by their colleagues and over-confident managers.

Just no one cared to educate them, but everyone expected "progress" from them.
So they did what they could..

In fact I wished many times that they used some abstraction layer which would
save them from doing such harm, simply because this layer would be written by
more educated people.

------
derefr
These arguments make me feel like DBMS technology is insufficiently
distinguishable from magic.

Databases do two things: they _persist_ data, and they _answer queries_ about
data. Neither of those requirements put any restrictions on how they
_serialize_ data. Relational storage, object storage, document-based storage,
key-value storage, graph-based storage, etc.—it all just seems like different
_optimizations_ on the same "real" data, something that should be abstracted
away from the database administrator entirely.

Why can't we just have a database that gets fed a normalized, relational-
algebra-style model of the data, but then _profiles_ the kinds of queries fed
to it, and the kinds of data given, and _builds_ whatever kind of denormalized
tables/indexes/k-v stores are optimal for your usage patterns, using a
Relational, or Object DB, or Graph DB, etc. engine when each is appropriate
(perhaps firing them off in parallel and returning whichever answer comes
first, killing the other threads)? Is this something anyone is working on?

~~~
silentbicycle
A "query optimizer", let's call it.

That'd be so cool. I wish RDBMSs came with query optimizers. Maybe something
that could ANALYZE (or, better yet, EXPLAIN) their performance, so people
could tune it.

And yeah, sarcasm aside, it's easier to have a DBA tune things than some AI -
of course: "Why can't we just have a compiler that gets fed a description of
the problem, then solves it, calculating the optimal solutions for all of the
engineering trade-offs, and then builds whatever kind of interfaces are
optimal for your users choosing Design Patterns as appropriate. Is this
something anyone is working on?"

~~~
derefr
Yes, RDBMSes already _have_ the capability to tell you how to best optimize
them. The problem—and it's a sociological problem, not a technological
problem—is that people don't _want_ to tune their databases. Instead, they
want to install something that is already tuned 80% correctly (i.e. a NoSQL
store), and then ignore the other 20% of possible optimization.

There's a big, unaddressed opportunity here: if you can just make your DB
smart enough to tune itself _81%_ correctly (and that's not very
hard—certainly not AI hard) then you can conquer the market for people who
don't know how to EXPLAIN their way out of a paper bag. It's not like it would
be inventing its schema on the fly; you'd still be feeding it a formal,
completely-specified _but unoptimized_ set of tables. It would just do things
like:

* Notice when it gets a query with the same parameters 10000x in a row, and grind out an index for it;

* Notice when a large (>100000) set of rows in a table is identical save for their primary key, and only queried by COUNT(foo), and turn those rows into a single row with a foo_count field (and a log table in case a query ever does come in that cares about the IDs);

* Notice when two tables are only ever queried joined together, and morph the primary store for them into a denormalized table, turning the previous, separate tables into views on the denormalized table.

And so on. If you look at, say, Python's hashtable library, it has all sorts
of these little "rules of thumb" for when to alter its internal
representation, because of what it guesses the user is up to (storing unique
pairs, creating mathematical sets, nesting hashes to mimic a complex data
structure, etc.) Databases, on the other hand, much bigger systems _purely
for_ flexibly storing and querying data, just stubbornly _sit there_ until the
DBA (because there must _always_ be a DBA, even if the DB is just being fed
migrations written by Rails CRUD coders) comes along to tell them to do the
things they already _know_ would make them faster. It's just silly.

~~~
jasonkester
Are you really saying that people are too lazy to draw lines between tables in
their database? Too lazy to right click a column name and click "Index"? That
you wouldn't notice on your own that a particular query took four minutes to
run and maybe open it up and poke around? That this should be something the
database does for you???

That is not the hard part of my job. That is the _easy_ part. No thank you.

~~~
derefr
But, as you say, it _is_ part of your job. The difficulty, or ease, of the
problem, has nothing to do with it; at some shops, it's _nobody's_ job, and so
it just _doesn't get done_. In 90% of shops, the last time anyone so much as
glances at the database is to run the CREATE TABLE query. No one profiles, no
one optimizes—you're lucky if anyone even declares any indexes (ahead of time,
as a guess, of course.)

And, consider: if it's the _easy_ part, why are [some] people switching to
NoSQL just to avoid doing it? ;)

~~~
wvenable
The most frightening part of this debate is that people who are too lazy to
properly define indexes are considering NoSQL solutions (and most of those
require indexes too)! Properly utilizing a NoSQL requires more work than an
RDMS, that's trade off for using a more low-level technology.

------
JoelMcCracken
I don't believe that there really are all of these developers around who lack
knowledge of SQL.

I learned SQL while I was learning to program. My very first (real?) program
was a php hit counter that wrote to a hits.txt on the server. My second one
was a guestbook that used mysql. My third one was a basic hierarchical forum.
I wasn't a wizard, I was just a kid reading a book, bored at the Pennsylvania
Farm Show.

Thus, I have spent my fair share of time working with sql queries in php code.
Guess what? The SQL queries weren't very hard at all.

However, SQL Queries had almost nothing to do with actual using SQL itself.
90% of the code written in such a project is guaranteed to be cruft code
surrounding the sql queries. Special cases abound. The difference between
"column = $val" and "column is null" is so painful that I just can't imagine
going through that anymore.

And that's just the first example! What does "" mean if you save it in a db
column? Should you save it as a null value, or as a string with zero
characters?

I just don't care about this at all, and you'd have to be a damned fool to
think that I would ever willingly go back to doing that bollocks.

I already have my in-memory data structure laid out. ORM lets me keep from
worrying about it it again (at least not nearly to the detail I would with
SQL). With an ORM, 90% of the database code that I used to have to deal with
is simply a non issue.

~~~
Confusion

        I don't believe that there really are all of these developers around who 
        lack knowledge of SQL.
    

I'm not sure why you don't believe that, but as someone that has done
development at a variety of companies: trust me, there are plenty of those.
They may even be reasonable at PHP or Java, but they couldn't subquery their
way out of a paper bag. At one place, the CTO, formerly main PHP/MySQL
developer, didn't know what an index was. You can figure out the rest ;)

~~~
JoelMcCracken
Sorry; I'm not saying that all developers know SQL. I'm saying that the ones
that we are all talking about know, or are competent enough to quickly know,
SQL.

To me, the people that you are talking about have no context in the discussion
in the least. They would be the last to jump on the NoSQL bandwagon because
they don't really care, for example.

The universe of discourse only includes the devs who care, e.g. the people who
are creating ORMs, using ORMs, using NoSQL, etc, not _all_ developers. I kinda
assumed that was implied.

------
kunley
This article has its amount of religious bias and wishful thinking. The author
tries to establish his base on a fact that SQL is all about relational algebra
and it's the right paradigm to query your data. While I agree with the latter,
the author (and lots of other people) seems to forget that SQL is a dumbed-
down-aimed-to-mediocre-programmers contraption _inspired_ by relational
algebra, but not really properly relational! It's really far from what Codd
had in mind. If you read the history of early SQL dialects and DB2 vs Oracle
competition it's clear that SQL was marketed as a language everyone can
program in (thus the stupid imitation of a natural language) -- we know in XXI
century that this is a bs...

I'd say that SQL is a COBOL of relational algebra...

~~~
Devilboy
Are there any (more suitable) alternatives to SQL?

~~~
silentbicycle
The K/Q people (<http://kx.com/>) have one interesting interpretation. It's
quite expensive for production use* and uses an APL dialect as a query
language, which tends to scare away a lot of developers. I'm utterly
fascinated with it, albeit from a distance. (J is cool, too, but doesn't come
bundled with a high-end in-memory database.)

* I've heard it can run $60k/CPU. It's designed for realtime stock data mining (<https://cs1.cs.nyu.edu/cs/faculty/shasha/papers/hpts.pdf>), so they get away with it.

~~~
mistermann
Can you give us some syntax examples?

~~~
silentbicycle
<http://news.ycombinator.com/item?id=1511121>

I meant to reply to this, didn't notice until after the edit window closed...

------
ignu
"The birth of ORM lies in the fact that SQL is ugly and intimidating"

The notion that people steer away from SQL because it is intimidating is
absurdly ignorant.

The communities that embrace ORMs and NoSQL are the ones who are learning and
creating new things all the time. No one's first language is Ruby, they didn't
learn node.js in college, they didn't take an (N)Hibernate certification
course. They learn in their free time!

Meanwhile, if you were good in SQL 12 years ago then you still are today!

Smarter people than me have written on these subjects, but for me, the answer
is simple. As Fowler says, the most pervasive smell in software is
duplication. If I litter my code with all the CRUD SQL (even worse with sprocs
that contain column sizes) then my software is quite brittle.

~~~
ora600
If you little all your code with CRUD, your code is horrible indeed.

If I hard code filenames all over my code, I also have horrible code. This
doesn't mean that files and file names are a problem or that they caused
duplication.

The normal (I hope) practice is to this in terms of transactions or activities
and create functions that wrap those activities. SQL should only live within
those functions that provide a logical interface to the DB. Its called TAPI or
XAPI (transaction API). Think of it as your own domain specific ORM.

~~~
gnaritas
> SQL should only live within those functions that provide a logical interface
> to the DB. Its called TAPI or XAPI (transaction API). Think of it as your
> own domain specific ORM.

Which is generally repetitive and full of duplication, exactly the thing that
drives people to use ORM's in the first place. It doesn't matter that it's
isolated into a separate layer, it's still more manual work than an ORM.

~~~
ora600
It is more work than ORM, but if efficient access to data is an important part
of your application, it seems to be extra work that brings benefits. At least
that has been my experience.

I'm not clear on why this layer has to be repetitive and full of duplication.

~~~
gnaritas
> I'm not clear on why this layer has to be repetitive and full of
> duplication.

Let's say you have a database with 100 tables in it. How many insert
statements might there be, just a rough estimate, in your layer of functions?
My ORM has 1. At the most basic level, a simple ActiveRecord ORM has 1 insert,
1 update, 1 detele, and 1 select statement. How many are in your typical app?
If it's more than 1 of each, then it's duplication.

I haven't written an insert/update/delete statement in years because I don't
need to. When I need a fancy select that's an aggregate of several tables, I
write a view and then map it into a list of objects with the ORM. This is
virtually no work, I spend all of my time working on the actual problem at
hand and virtually none marshaling data in or out of the database.

~~~
ora600
I'm totally not following here...

How can multiple insert statements be considered duplication if they are
inserting different things to different tables? My apps have multiple insert
statements. They also have multiple calls to "print". Do you count that as a
duplication as well?

We can continue the discussion by email if you prefer. It is interesting to
me, but we may be getting off topic.

~~~
gnaritas
> How can multiple insert statements be considered duplication if they are
> inserting different things to different tables?

Because they're all the same pattern of code. Whenever you see common
patterns, you're missing an abstraction that can greatly simplify things.

Why would I write 100 different insert functions when I can write one that
generates itself dynamically using reflection over whatever object it is
given? You only need one insert statement, it just needs to be smarter rather
than static hand written code.

You need only tag your objects with a little bit of metadata using attributes
to give a generic insert/update/select/delete everything it needs to
dynamically generate parameterized statements on the fly for every table in
the db that you use. Put simply, the only thing I need to do to use a User
table in an app is write something like the the following...

    
    
        class User : ActiveRecord<User> {
            [PersistentString(MaxLength=50, Required=true)]
            public string UserName;
    
            [PersistentString(MaxLength=50, Required=true)]
            public string Password;
    
            [PersistentString(MaxLength=5000)]
            public string About;
    
            public User(){}
        }
    

And I'm done, I can now Find, FindAll, Save, Delete, Count, Sum, Min, Max,
Avg, Count, Exists, Not Exists, etc... on those records without writing a line
of SQL. All of these methods are inherited from the superclass and work on the
table User. The same thing applies to view and stored procedures.

------
ifesdjeen
Well, it's all happening now. First step towards that which I noticed is
Moneta (Ruby gem), that is giving you some abstraction over key value stores.
I don't think that it's a whole lot of performance overhead and it does let
you switch when you realize it's time to.

Overall, you may also want to use orm for sakes of interchangeability of your
SQL as well, and it certainly gives you advantages.

Im working on a project that involves no orm and uses oracle as a primary data
store. Though I don't want to install oracle On my machine but repository idea
built-in to project doesn't let me use postgre for development. And yet schema
creation involves varchar2 that's simply inaccessible in postgre. Its quite
easy to fix but I'd expect to have some kind of a fallback....

In any case, it's a good point that key-value storages are not for every
problem, but that's quite obvious. someone said that every time you say
"nosql", a kitten dies. so, careful there.

------
rlpb
SQL always seemed to me to be the way it is in order to lend itself to
optimisation at the database end. It is easy to look at any SQL query (that
doesn't use subselects) and see how the DB engine can efficiently execute it
by walking down the appropriate indexes.

Try doing that with an ORM or a key/value store.

~~~
jbarciauskas
Can you elaborate the issues an ORM has in dealing with indexes? An ORM can be
made aware of indexes via, e.g., annotations or other declarative syntax, and
prefer those when joining and filtering, and will probably be more consistent
about it than a human developer.

~~~
rlpb
I didn't mean that ORMs have problems with indexes; just with efficiency:
because you can tell the SQL engine what you want done instead of having to
bring the data to the code (in particular when iteration can be folded into
the query).

~~~
jbarciauskas
Yes; but even this only goes so far. Execution plans change based on
statistics collected by the query optimizer. SQL was invented because query
optimizers do a better job than humans. The same is commonly true for ORMs.

------
forkandwait
In defense of SQL syntax, I think that, in its very constrained domain, it
models table / set operations with the best balance of expressivenes,
readability, and generality today. At least compared to any other syntax I
have seen, including ORM's. We take our old friends for granted until they are
gone, and I have had to work with a number of data environments without SQL
and its lack was _sorely_ missed. The SAS community was overjoyed at the
addition of PROC SQL for this reason, and the goofiness one has to do in R/
SPLUS is quite unpleasant.

~~~
ora600
Even in its own domain, SQL sacrificed parsing for "user friendly" English-
like appearance.

SQL error messages are very unhelpful in every DB. You can't easily debug
misbehaving queries and there are no tools to help. There is even a lack of
indentation standard.

Fixing very long queries that fetch the wrong results is something I've been
doing daily for the past 10 years of my life. It is not easy, and I believe
the language is to blame for a large part of the difficulty. In some aspects
of doing unexpected things with no warning - it is worse than C.

~~~
jerf
Further: SQL is not composable. If I have a fragment of SQL in my hand, there
is no reasonable way to insert that into a larger expression. You can further
tell this is a problem by the way any nontrivial SQL function degenerates into
an enormous hellstorm of SQL that any Haskell programmer will see as full of
redundancy. This is because SQL is almost immune to abstraction. (I have to
specify the "Haskell programmer" bit because of the characteristics of this
sort of language is that working in it directly for a long time causes you to
think natively in that language and thereby miss the opportunities for
abstraction that you _no longer see_. FWIW, Erlang also bothers me this way.)
Yes, the "bad programmer" issue is in play too, but as a good programmer who
has tried to write good stored procedures and has experience in numerous other
languages I can not help but notice how much SQL _fights_ me on this front.

SQL is very difficult to debug in general, which combines rather poorly with
the previous characteristic. Perhaps there are nonstandard extensions in
Oracle that make it easier but there's nothing I know of in the core language.

SQL has fooled people into thinking it is equivalent to the Relational Model,
when in fact as kunley points out elsewhere it is merely _inspired_ by it.

SQL dates from the 1970s and _it shows_. There are syntax quirks around every
corner. The behavior of NULL is sensible, but it is merely one of several
sensible choices and there are reasons why the SQL choice is not the one that
has "won". Why is "value IN ()" a _syntax error_? It's perfectly reasonable.
What's with the syntactic drama around subselects, which ought to be a core
part of the better language that we really ought to be using? (A language in
which the equivalent is probably going to be so simple we won't even believe
people had a special syntax for it.) What's with the rigid specification of
the order of GROUP BY and ORDER BY and everything else, when those should
simply be instances of some sort of combinator that applies in order, in a
sensible manner. Why is SELECT used both for data queries and aggregate
queries when in fact the two operations are so different they should have
entirely different keywords? Why is it so hard to mix an aggregate and non-
aggregate query together when it's obvious to me exactly what I want?

Why can't my columns contain tables themselves, recursively? The fact that
there are databases that can do this proves it's not impossible.

SQL needs to be replaced by a combinator-based language that backs to a richer
data store that is more sensible, both from a relational model point of view
and from a recursive point of view. LINQ points the way, but still is hobbled
by LINQ-to-SQL being the flagship LINQ product. (And I don't think it's
complete as-is.)

~~~
ora600
I completely agree with every word you said.

But why do you want columns that contain tables recursively?

Aggregate and non-aggregate mixture is supported in the standard and Oracle
with the analytical expressions (if I got your meaning correctly).

~~~
lmz
Why not columns that contain tables? It would certainly make things easier.
e.g. Get a list of customers with their orders:

SELECT ... FROM customers LEFT JOIN orders ...;

To get this into a presentable table, I would have to keep track of the
previous customer's ID and only start a new row if the current customer ID is
not equal to the previous customer ID. If table-valued columns were available,
each customer row would have a column containing a table of their orders.

~~~
ora600
I have a problem with designing a data model with the "ease of displaying it
in a pretty way" as the main consideration.

Nested tables may well be the bee's knees, but probably not for this reason
alone...

------
DjDarkman
Very good article, I myself have found the "NoSQL" label pointless, when you
label something you normally tell what it is, instead of what it's not.

~~~
cheald
"NoSQL" is generally understood to mean "Not Only SQL", not "SQL is evil,
begone foul beast".

~~~
ergo98
>"NoSQL" is generally understood to mean "Not Only SQL"

I think that that is a bit of convenient revisionism as it becomes clear that
the Emperor is wearing no clothes.

There absolutely was a very antagonistic, "this changes EVERYTHING" philosophy
behind the movement called NoSQL, and the name is not accidental. Perhaps it
was just a bit of trolling to get attention, but in no way was it a live and
let live initiative (data tactics that are now bound in "NoSQL" long existed
in computer science, since before the days of SQL. They just didn't feel the
need to make it a comfortable community of evangelists). It was a "that was
yesterday and this is today".

Of course things have changed. A bit of realism entered the mindset, so now
it's more of a "Heh heh...no bad blood right? We're all good, eh?"

~~~
mathias_10gen
Actually the name was very much accidental. Read this post by the guy who
coined the term: [http://blog.sym-
link.com/2009/10/30/nosql_whats_in_a_name.ht...](http://blog.sym-
link.com/2009/10/30/nosql_whats_in_a_name.html)

"it was one of 3 or 4 suggestions that I spouted off in the span of like 45
seconds, _without thinking_."

~~~
ergo98
>Actually the name was very much accidental.

Spur of the moment isn't really accidental, any more than Mel Gibson
accidentally said the N-word. There's a bit of a history and a thought process
that leads to such a decision.

------
niels
The NoSQL datastores are aimed at solving scaling issues. The current
relational databases are a pain to scale. It's not about hating SQL.

------
alrex021
_> Awkward it may be, but SQL is a lot more succint and readable than multiple
lines of API calls or crazy, math-like relational algebra languages._

I'd have to totally agree with this. SQL also achieves higher level of
abstraction than any of the above.

Perhaps, as the author said, there is a chance that SQL (or subset of it) will
be used as the query language for _No SQL_ -type back-ends.

------
thomasfl
If you know just a tiny bit of relation algebra, then sql is not hard at all.
I love ActiveRecord, since it makes you mix the DSL and SQL. Hibernate is
impressive, but sometimes i miss SQL, and get's frustrated with it's HQL.

------
RyanMcGreal
>It triumphed over other query languages not because it was particularly great
(though it was easier to read), but because it was standard.

Isn't that a tautology?

~~~
DrJokepu
Not all standards are popular. Microsoft's OOXML, for example, is technically
an ECMA and ISO standard but I wouldn't call it exactly popular (even though
it's widely used due to Office's market position). Because being a standard
does not always imply popularity, the statement is not a tautology.

