What? SQL is virtually plain English and is efficient across a range of database architectures for moderate-to-complex join situations. Its just an implementation of Boolean Algebra with a thin abstraction layer that uses words like SELECT, JOIN, FROM, WHERE, etc.
If you have performance issues, its invariably because the structure of your data is less than optimal or you have many linked external tables. Or -- you are really bad at efficient query design. Even highly experienced SQL-ers always look at old queries and realise that they could be three times faster and half as big, and if there is a performance issue then that's the first thing they'll review.
Humans have been 'understanding' SQL very well for nearly forty years -- without modern refinements like graphical query designers, either.
Not all data is a suitable candidate for an RDBMS solution, I am the first to agree, but there's not actually much wrong with SQL when what you need is a relational table store.
There are a few bad implementations of it, though, it is true, and a lot of people who can't seem to grasp SQL for what it is.
Edit: I am myself a huge fan of NoSQL solutions and always seek to rationally justify a non-relational datastore solution where practical or possible. NoSQL isn't a replacement for SQL (with all its imperfections) for the kind of slicing and dicing where it is needed.
SQL is a very, very poor implementation of relational algebra. For example, the output of an SQL query is not even a valid relation variable (in E. F. Codd's terminology).
If you want to look at how SQL might have looked if it had been relational, take a look at "Tutorial D", the language proposed in a book called The Third Manifesto, by Hugh Darwen and C. J. Date: http://thethirdmanifesto.com/. There are several experimental implementations.
Comments
* COBOL-inspired syntax that is neither human or machine parseable (easily).
* Strange nested query rules
* Language encourages Cartesian products for virtually every non-trivial calculation. This makes join order crucial for reasoning about performance.
* Humans don't have the brain capacity to reason about these joins, forcing the logic onto the query planner.
* Humans don't have the brain capacity to reason about the query planner reasoning about the joins.
* End result: bizarro-english syntax that's supremely hacked-up to twerk the query planner to do your bidding.
What? SQL is virtually plain English and is efficient across a range of database architectures for moderate-to-complex join situations. Its just an implementation of Boolean Algebra with a thin abstraction layer that uses words like SELECT, JOIN, FROM, WHERE, etc.
If you have performance issues, its invariably because the structure of your data is less than optimal or you have many linked external tables. Or -- you are really bad at efficient query design. Even highly experienced SQL-ers always look at old queries and realise that they could be three times faster and half as big, and if there is a performance issue then that's the first thing they'll review.
Humans have been 'understanding' SQL very well for nearly forty years -- without modern refinements like graphical query designers, either.
Not all data is a suitable candidate for an RDBMS solution, I am the first to agree, but there's not actually much wrong with SQL when what you need is a relational table store.
There are a few bad implementations of it, though, it is true, and a lot of people who can't seem to grasp SQL for what it is.
Edit: I am myself a huge fan of NoSQL solutions and always seek to rationally justify a non-relational datastore solution where practical or possible. NoSQL isn't a replacement for SQL (with all its imperfections) for the kind of slicing and dicing where it is needed.
SQL is a very, very poor implementation of relational algebra. For example, the output of an SQL query is not even a valid relation variable (in E. F. Codd's terminology).
If you want to look at how SQL might have looked if it had been relational, take a look at "Tutorial D", the language proposed in a book called The Third Manifesto, by Hugh Darwen and C. J. Date: http://thethirdmanifesto.com/. There are several experimental implementations.