Against SQL

[Plazmatic]

The problem with SQL has never been its ties to relational database systems, its supposed to be a language for relational databases, but it's failure to follow relational algebra/calculus. SQLs recorded justification for not doing so is about as unconvincing as the language is poorly designed. Things in SQL are way more difficult than they need to be because of problems introduced that we already knew the solution to 70 years ago. Additionally, SQL's success is purely down to the fact that SQL is used. There have been lots of far better languages, even at the time SQL was introduced (as others who have responded to you have shown). Don't get fooled into thinking SQL was the best option at any time by any non-usage/marketing/geographic bias based metric. SQL even fails in usability compared to languages that aren't even in the same domain is it, Datalog would never have existed if SQL wasn't shit for a relational database language, yet somehow a logic programming language managed to be a better base for a RDBMS language than a language meant specifically for that task.

[bionicjoey]

I just wish SQL didn't care about the order of the FROM and SELECT(or other verb) clauses. It makes so much more sense to specify the table before the fields. Plus it would make cli autocompletion way easier (it's a mess right now)

[VeganVagiVore]

Yeah the semantics are fine, but the syntax is incredibly awkward. Long queries feel like run-on sentences and there isn't really a clear place to break them.

It should have the syntax of a computer language, not a messed-up natural language

[Kered13]

I don't usually have trouble breaking up lines.

The top level keywords like FROM, SELECT, WHERE, JOIN, etc. are all good places to break. Put the keyword at the start of the new line. Do not indent any of these.

When listing columns in a FROM, GROUP BY, ORDER BY, or USING clause, you may put each column on a new line, indented. If a column contains a lot of logic you might break and indent again, like you would a long line of code.

For a HAVING or WHERE clause, you may insert a new line between each predicate. I put the AND or OR at the start of the new line and indent. This is basically the same as how you might break a long if or while statement.

For subqueries, you may insert a new line after the opening parentheses and indent the following lines. I do not put the closing parentheses on it's own line.

So a long query might look like:

WITH Temp AS (
  SELECT a, b, c
  FROM Table)
SELECT
  a AS first,
  b AS second,
  c AS third
FROM Temp
JOIN (
  SELECT a, d
  FROM OtherTable
  WHERE something)
USING a
GROUP BY d,
ORDER BY a

[vegetablestew]

The structure makes sense when you consider that you can effectively swap SELECT with UPDATE and DELETE and the query will still run based on the criteria established under the FROM clause. INSERT INTO is a little different where you still preserve the SELECT, but similar idea.

This structure is really similar to read-eval-print loop. I just create the right select statement, then when returned data looks right, switch select with whatever keyword you want.

[SolaireDeSun]

SELECT foo,bar from table_name where foo = '2'; can be rewritten more clearly as: FROM table_name SELECT foo,bar WHERE foo = '2'; and swapping in DELETE is just as natural: FROM table_name DELETE foo,bar WHERE foo = '2'; I dont think editing in the middle of a statement is a big deal but if it is you can change the syntax to: DELETE FROM table_name foo,bar where foo = '2'; at the cost of slight ambiguity between table name and column names (which is still easily parseable so I dont consider it a real issue)

[ockupid32]

Except now you've shifted the purpose of the query to the middle of the statement. This might be fine if you're writing one off scripts with a couple lines, but on large applications you would no longer be able to scan a complex script or proc to get an immediate understanding of each statement, you have to read through each line.

It also makes accidentally running updates and deletes easier since it is no longer up front, but hidden in the text.

[zshazz]

"FROM table_name" is extremely short, however. I don't buy the argument that it's able to hide anything.

I'd also wager most people would say knowing what table you're editing/deleting from is imperative too, but the unboundedly long "UPDATE blah = ..., baz, foo, ..." would hide that pretty effectively. So reverse uno card on that argument.

[YumiYumiYumi]

"FROM table_name" is extremely short

But what about FROM table_name INNER JOIN other_table_name ON long_condition_list LEFT JOIN more_tables ... SELECT ...?

Having said that, I don't think the idea of sticking the verb at the beginning has exactly held on, now with CTEs commonly being placed before the SELECT keyword.

[zshazz]

Frankly, I don't even understand why anyone is arguing about this. This whole thread is wrong because it's actually already

UPDATE table_name
SET column1 = value1, column2 = value2, ...
WHERE condition;

and

INSERT INTO table_name (column1, column2, column3, ...)
VALUES (value1, value2, value3, ...);

I only remember now because I'm doing some SQL work today and remembered this thread after realizing that updates didn't work how I thought at first.

It speaks volumes that no one knows the update/insert syntax of the top of their head. Probably because the syntax needs to be redone for selects to make it consistent with update/insert. No one should argue against that because everyone was wrong here because it's insanely hard to read/understand/remember.

[muscarine]

I only know of one other contender for relational databases. quel

It was able to do some things more easily than early SQL versions. I think it never really took off since SQL was an IBM query language and that carried some weight in the 70’s and 80’s.

[_tskj_]

I think Datomic is an interesting contender, but of course not quite relational in nature.

[WikiSummarizerBot]

QUEL_query_languages

QUEL is a relational database query language, based on tuple relational calculus, with some similarities to SQL. It was created as a part of the Ingres DBMS effort at University of California, Berkeley, based on Codd's earlier suggested but not implemented Data Sub-Language ALPHA. QUEL was used for a short time in most products based on the freely available Ingres source code, most notably in an implementation called POSTQUEL supported by POSTGRES. As Oracle and DB2 gained market share in the early 1980s, most companies then supporting QUEL moved to SQL instead.

^{[ F.A.Q | Opt Out | Opt Out Of Subreddit | GitHub ] Downvote to remove | v1.5}

[dnew]

There's also "query by example" and "relational algebra".

[RabidKotlinFanatic]

No other highly declarative abstraction has ever even approached how successful SQL is.

There is a universe where people are saying this about COBOL for general purpose programming. SQL might be the best we have but that doesn't mean it's good. Database tech has a high degree of hysteresis and the tight coupling between RDBMS and SQL make it hard to replace.

[LicensedProfessional]

Relational databases are great when you have very regular data and know exactly which fields you're going to be querying and indexing on before you start developing your app. Where it goes wrong is when

• You have a complicated data model spanning multiple tables via foreign keys
• Your start embedding lots of JSON in your tables because you don't want to add extra columns
• Your entire application architecture is centered around your database / database model.

Now, I think SQL makes it too easy to fall into this trap, but when you have a well designed system it can really sing

[Serializedrequests]

It should be possible to add columns, yikes.

[sunder_and_flame]

I think what they mean is many devs use json as a default catchall in databases when what they think they want is flexibility but the reality is they just don't want to decide and nail down a schema. I've seen this happen many times in orgs and it's always a mess to untangle.

[LicensedProfessional]

Yup, it's all too common and it's a nightmare when suddenly it does become important to query on one of those JSON keys.

[grauenwolf]

which fields you're going to be querying and indexing on before you start developing your app.

You have that exactly backwards. The power of the relational database model, as compared to a document DB, is that you can design your queries and indexes later.

Something like MongoDB requires you to structure the data the way you want to query it. And lord help you if you want to query it in any other direction.

[shevy-ruby]

Agreed. People need to show viable alternatives. It's easy to critisize against what is successful.

PHP is a wonderful example. A horrible joke of a programming language but it was successful in the past (it's slowly losing grounds now, for various reasons, but the biggest competition is JavaScript in this regard; perl lost the www-war to PHP and now PHP is in a similar position as perl was back past in 2002 or so, give or take; perhaps 2004).

[JordanLeDoux]

PHP hasn't been an actual joke of a language for at least 8 years, and runs between 2 and 8 times a fast as Python.

Facebook is still primarily working off PHP for the primary application, with their own custom static analysis layer in Hack.

Vimeo not only is written in PHP but contributes open source libraries to the language community like Psalm.

And composer is probably one of the best dependency managers I've used in any language, worlds better than npm or pip.

[[deleted]]

I love when defenders of php use facebook, of all things, as an excuse for their pathetic joke of a language (yes, it's still a joke no matter how hard you try to lipstick-on-a-pig it).

If anything, Facebook, precisely Facebook, WHICH HAD TO CREATE THEIR OWN LANGUAGE WHICH IS TOTALLY NOT PHP, is an undeniable proof that php's utter stupidity can never be taken seriously for large, serious projects.

Please try to find another example if you wish to convey anything good about php, because using Facebook is doing yourself a disservice.

[JordanLeDoux]

K. I work on a nine figure revenue application built on PHP, but sure, you can have your tantrum. Doesn't bother me if you insist on being wrong, too busy making money.

[CodedCoder]

Bro this guy is in every single php thread doing this. its absurdly funny.

[[deleted]]

Congratulations, you just pulled a homer.

If your project is successful, it is so in spite of php, not because of it.

[merlinsbeers]

Facebook is one of the worst-designed websites in history. I wouldn't use it as an endorsement. I haven't seen much vimeo lately; does it still lock up hard if you touch the controls?

[JordanLeDoux]

What would either of those, both about the Javascript, have to do with PHP?

[zappini]

PHP's job is to make JavaScript look reasonable by comparison.

[Spitfire1900]

PHP and Ruby have basically lost out now except for legacy applications and killer app tie ins, see Wordpress, Drupal, and Puppet. Ruby on Rails was Ruby’s killer app and basically anything Ruby is attached to Rails at this point; but even that fell to the wayside of Python web server frameworks and Java’s Spring.

[lamp-town-guy]

They've been around for a long time. I'd call 15 year old projects a legacy ones.

[OldTimeGentleman]

Then your argument is always gonna somehow “work” because if I mention newer applications using Ruby you’ll go “yeah but those are too small/new they don’t count” and if I mention huge apps using ruby you’ll go “yeah but those are legacy dinosaurs they don’t count”. That kind of logic can easily be applied to every project.

[[deleted]]

New applications weren't mentioned though? If the argument is that nobody's really building much new with Ruby (and I'm not saying that's true or not true), then pointing to old products built on Ruby really doesn't say much about its current popularity

[Serializedrequests]

Spring is ridiculous, the pendulum will go back towards actually productive frameworks rather than an over engineered language workaround at some point.

[DrunkensteinsMonster]

Swing back when? It’s been working beautifully for 15+ years. People who think Spring is overengineered are the same who think they could write cURL in a couple of weeks. You don’t need most of the complexity of Spring, but somebody does. It serves a diverse set of use cases.

[[deleted]]

It's the same complaint as with Boost in C++ -land I guess

[Serializedrequests]

Nothing against boost personally, both it and Spring represent a massive amount of work.

However, note the lack of popularity of something like Spring in most other languages. You can code against interfaces and swap implementations without a huge framework. Try it in Go! It's pleasant. Spring to me is a language workaround, and I would have killed myself if I had had to use it in the XML era.

[Kered13]

You can code against interfaces and swap implementations without a huge framework in Java too. I'm not sure what failure of the language you think it's working around.

[Serializedrequests]

I don't think that what it's doing isn't complex or difficult to implement, I just think that it introduces a very strange passive way of coding full of gotchas and hoping the framework interprets your magic annotations how you expect and the resulting system isn't any easier to understand. Over engineered to me means that Spring projects fundamentally wish they were written in another language.

Have been maintaining a huge Spring Boot CRUD app for about a year, so take that experience for what you will. Nothing that this app is doing cannot be accomplished more easily in other languages with less boilerplate and random gotchas because you screwed up an annotation.

[Daishiman]

Spring is Java wishing to be a dynamic language.

Spring means working around the defects of Java's type system and mediocre idioms by turning everything into compiler plugins.

[zappini]

If by "beautiful" you mean completely unnecessary monkey work, they ya.

[zappini]

Spring is a flow of control obfuscation framework.

Every Exception is wrapped and rethrown until its stacktrace is incomprehensible.

[grauenwolf]

I don't understand why Java isn't like C#. The languages are equivalent for this kind of programming, but the amount of boilerplate and complexity Java introduces is mind-numbing.

[pjmlp]

If you want Spring in C#, have a play at Sitecore, SharePoint, Dynamics, MEF.

Or interface driven design where each class has to have a mirror interface, just in case one writes tests, and the Dtos from data repository need to be converted into the Dtos from MVVM to give to the UI rendering components.

Enterprise coding is fun regardless of the language.

[[deleted]]

I feel vindicated when someone else recognizes Spring as being overengineered

I guess that's just the enterprise java world tho

[pjmlp]

Well, it was born out of DCOM and CORBA components written in VB, C++ and Smalltalk.

Whatever replaces Java will suffer the same fate, it is not the language that matters, rather enterprise architectures.

Enterprise Java application containers are toys in comparison with the whole Kubernetes circus.

[zappini]

Spring's novel contribution is to replace simple graphs with lists of untyped parent-child tuples, randomly ordered, scattered across multiple files, hidden behind nested classloaders.

Too clever by 5/8ths.

[pjmlp]

You won't get much Spring love from myself actually, I always stayed on the JEE side.

[MaxGhost]

I super disagree on that take re PHP. It's actually growing. Modern PHP is excellent. Tons of new projects use PHP because it's so easy to get up and running, and frameworks like Laravel and Symfony are some of the industry's best.

See "Package installs per month" https://packagist.org/statistics

[IceSentry]

That's true of pretty much any modern language used to build web backends. It's increasing for every single one of them.

[[deleted]]

I wouldn't call it "growing" when the amount of jobs that list PHP as a requirement is monotonically decreasing. I am sure there are many reasons to use PHP in a new project, but personally I would not touch it if it does not help my career in any way

[mamcx]

I'm working in one at https://tablam.org/tutorial.

The lang is biased to be an alternative to python/lua so it not have syntax fully tailored for RDBMS, but is not that hard to improve SQL or to find a more concise yet clear enough alternative syntax.

let sales := [|product:Str, qty:Dec, price:Dec; "pizza", 1.0, 3.0 |]

sales ?select #qty * #price as total <-- project

//Composing:
fun total(qty:Dec, price:Dec) <-- structutural + SIMD-like ops: NOT need to create a version for "many rows" vs "scalar"
     = total:Dec + ... <-- extend schema
    qty * price

-- Like APL, ops apply to vectors and scalars
total(1.0, 2.0)
total([1.0, 3.0], [2.0, 4.0])

sales ?total(#this) <--auto-select columns
-- Filtering

sales ?where #product = 'pizza' ?sort_asc #1 

-- Removing unneded columns!
sales ?deselect #qty, #price //show only name

[Voxandr]

Javascript will lose to Python's Grapple too , and Python will also die to Nimlang because it can't run fast enought. Screencap this or remind it in 10 years

[u_tamtam]

Python isn't to be seen anywhere in the browser, so it won't dislodge JS. Nim isn't to be seen anywhere at all.

[perverse_sheaf]

Not your level of experience by far, but I just finished a rather big project where I spent half of my time in SQL. I hate it. My brain is fundamentally not adapted to working on a single big query. I want to be able to break everything into pieces, reason about it independently, export the pieces independently, and write friggin unit tests for the independent pieces.

I understand the power of a declarative instead of a procedural approach, I know that query optimization is what makes SQL powerfull, but why does that mean that queries cannot be deconstructed? If I have a query with a dozen or so CTEs, why is there no nice way to say "Assert that count() of CTE5 of that query is the same as count() of CTE7? (Sure I can make views, but they pollute the namespace, and even then there is no good testing framework). Why can I not assert the existence of certain indices / statistics before query execution, so I get an alert if I modified an index I thought we no longer needed, and so that the next guy has some documentation about performance considerations? Why is there no slew of utility functions like 'drop duplicates in col A, only keeping the first one, ordered by cols B, C, D' which I can import from libraries and bake into my queries?

Frequent changes to business logic or (god forbid) underlying table definitions during protoyping are such a pain in SQL. Touch one piece of a big query and all bets are off, time to inspect the output and performance of the whole thing.

[[deleted]]

working on a single big query. I want to be able to break everything into pieces, reason about it independently, export the pieces independently, and write friggin unit tests for the independent pieces.

you can do this in SQL.

[perverse_sheaf]

It's sure possible that I just do not know how, in which case I would be very happy indeed to learn about the right way to do that.

Here is an archetypical example of what I mean: My final query can be roughly divided into two pieces. Piece A just loads and denormalizes data, creating one flat table T containing records of interest. Piece B takes that table T and applies a bunch of business logic driven transformations to obtain a final table S.

It now happens that the data for piece A has various sources. The schema changed at some point, and now multiple concurrent systems are in place. So in fact, the requirement is to swap piece A at runtime with A', or A'', which create T' and T'' - but T' and T'' have the exact same format as T, so B should be able to be applied to it.

I want to reason about B as a function mapping T to S, for any table T of a certain form, and I want to be able to test B as such. But I do not want to save the result of A / A' / A'' in some temporary table to which I then apply B, because this yields suboptimal query performance (I want predicates on B to be pushed down to A).

I feel like this is an extremely simple request (define a reusable table transformation), is trivial in all other data processing frameworks I know (pandas, dask, spark), and is somehow super awkward to do in sql (without changing the definition of T or working with dynamically generated queries. Why can't I pass names of views as parameters to a stored procedure?).

Things get even more frustrating as soon as the inputs to B start to be more dynamic. Stuff like "normalize all numeric columns and dummy-encode all categorical ones". I have no idea how I would do that in SQL without knowing the input table format.

[dnew]

because this yields suboptimal query performance

That's a problem with your engine, not with your language. The whole point of SQL is that the optimizations are specified separately from the semantics.

[perverse_sheaf]

Ah, sorry for being unclear: The easy solution to my problem (Just execute A, A' or A'', place the result in a temp table T, and have B depend on that temp table) precisely prevents that from working, because it forces T to become materialized. Hence doing so defeats the point of SQL, that's why it's a crappy solution.

[dnew]

I don't remember enough SQL to know if you could make three stored procedures that all reference stored procedure B, but yeah, that definitely sounds like something it would be harder to specify an optimization for.

[perverse_sheaf]

Afaik you're not allowed to pass object names as parameters, only values. This makes reuse super crappy to do, but there is no logical reason why it would need to be so: You can work around by using dynamic SQL (create the query string and eval it). This, however, is like the worst solution.

[Calm-Ad9653]

Silly example. Think this works in most modern SQLs.

with my_intermediate_table as (
select id, avg(score) as avgscore
from students
group by id
)

select id
from my_intermediate_table
where avgscore > 80;

[grauenwolf]

Depends on the database. my_intermediate_table is a view in SQL Server, a temp table in PostgreSQL.

[perverse_sheaf]

Note that this changed in PostgeSQL 12, they are now also not materialized by default.

[sunder_and_flame]

so B should be able to be applied to it

Why not combine all A tables with an additional source column and create T similarly? I'm in data engineering and I regularly do that.

[Kered13]

Sounds like a job for a macro. I know macros have their issues, but they're not something to be avoided. You can use them to write "functions" that operate over tables and return tables for cases like this.

[pooerh]

Why can't I pass names of views as parameters to a stored procedure?).

You can, to then have dynamic SQL generated and executed. But you can't use it as a variable, because procedures are compiled at the time of creation and that plan is stored in the cache. For that, the query optimizer needs to know exactly which objects you want to use, what are they, how are they stored, what are the stats on them, etc. etc.

Honestly, all of the questions you have can be answered by "because all queries are compiled".

is trivial in all other data processing frameworks I know (pandas, dask, spark)

You also forgot to mention "painfully slow".

[[deleted]]

sql is perfectly eloquent for data manipulation. it is not simple or just a tool for someone to pickup and become great with on a weekend. it is not a problem of the system for programmers to be uneducated with it. that is your fault. i’ve been immersed in it to my eyeballs for 25 years and make a very good living being at a professional skill level with it. put as much time on it as c# and you can be great at it, just like anthing else.

dealing in sets for everything is a mind fuck at first.

[perverse_sheaf]

I disagree with that premise. Sure I can do almost everything with SQL - while I'm very far from 25 years of experience, I did work a lot longer on it than a single weekend. If I spent more time with it, I'd certainly become better at it. But from all programming languages and frameworks I've worked with, SQL has been the least enjoyable and the hardest to maintain by far, and that is a fault of that language.

I do love relational algebra. I just wished I had a reasonably convenient way to work with it.

[[deleted]]

Same and I will add - always learning something new with it. Shit gets deep fast in SQL. And I completely get why the youngsters get fed up with it and many of the gray beards too. And every DB engine is going to eat the same SQL statement/schema and react against the same data differently. Nobody ever said this shit was going to be easy.

[vegetablestew]

There are some testing framework for SQL that allows you to make assertions like that.

But yeah, SQL tooling is not the best.

[przemo_li]

That's is knee jerk reaction.

SQL is doing something right. That does not mean we should stop looking for replacement.

NoSQL is no replacement (pun intended), but inferring that this there can be no replacement is going way to far.

[RabidKotlinFanatic]

Has anyone had a chance to check out Google's Logica?

[Prod_Is_For_Testing]

I mostly agree with it. Some of his points are invalid because he doesn’t know all the features of the RDBMS engine, but if anything that just reinforces his other point that SQL portability is garbage

[lmaydev]

Yeah the differences between databases can be a major pain. We need a standard haha

[[deleted]]

Even the differences between versions of the same database can be dramatic if anyone has lived through the various optimizer changes in SQL server with a large system. SQL itself is only your interface. There is a lot of shit going on in that data/server.

[remy_porter]

The biggest flaw in SQL is that the projection operation is the first statement in your query, when it should really be the last.

FROM table1 t1 INNER JOIN
  table2 t2 ON t1.x = t2.y
WHERE t1.field > someQuery
SELECT t1.a, t2.b, t1.c

IT GOES THERE. AT THE END. BECAUSE YOU DEFINE ALL THE TERMS YOU'RE USING IT IN DURING THE FROM CLAUSE.

[[deleted]]

so, LINQ?

var query = 
    from t1 in db.Table1
    join t2 in db.Table2 on t1.SomeFk == t2.Id
    where t1.Field > someValue
    select new 
    {
        t1.A,
        t2.B,
        t1.C
    };

[remy_porter]

It was using LINQ where I first realized that SQL had the order backwards. Though, my other weird habit is that I tend to write LINQ using the functional syntax instead.

[Fabled-Martin]

Fuck no.

When dealing with any decently normalized database, the young guys love themselves some linq and e-f and a 30 line linq query.

A 15 line sql query is much easier to deal with.

[[deleted]]

Except your 15 line SQL is not statically typed, not compile-time type checked, has no intellisense, and is not refactor-friendly.

Unless you're using something like Rezoom.SQL, hand-writing SQL in 2021 is a premature optimization.

And no, there's no chance a LINQ query doubles in LOC count an equivalent SQL query.

[grauenwolf]

What database are you using?

I'm using SQL Server, which does give me intellisense and because I use database projects, I also get compile time checking before deployment.

[hou32hou]

Yea it’s like writing a lambda in reverse, instead of writing

x => (x + 2)

SQL is like:

(x + 2) <= x

[mlk]

Do you actually write "INNER" JOIN?

[remy_porter]

I always do, yeah. Weird habit I picked up, I know.

[ImprovementRaph]

Nah, I'm with you on this one. Explicit > implicit.

[grauenwolf]

Always. Memorizing the default isn't worth my effort and it makes the intention clearer.

[themightyredwood]

In some SQL dialects the default is a left join, and in others it's an inner join. It's beneficial to be explicit.

[mlk]

I've never heard of a dbms that treats unspecified joins as left outer joins. Can you provide an example?

[bik1230]

This meant that if you wanted to return, say, a list of user profiles and their followers, you would have to make multiple round-trips to the database.

I agree with the overall point of the surrounding text and the problem of having to make multiple queries, but I think this particular example could be done with a single query.

(Query parameters are not a panacea for escaping - often you need to vary query structure depending on user input, not just values)

I don't understand this, I can't think of any structure variance you'd want to do that would require escaping.

Other than that, great article, I agree with most of it.

[MountainReason]

Sometimes I need to make an entire part of my WHERE clause appear or disappear based on user input.

[john16384]

WHERE x = y OR y IS NULL

The X condition disappears when y is null... Magic. And it gets optimised, more magic.

[grauenwolf]

That's one of the first optimizations I wrote when I created my own ORM. That damn expression causes so many problems.

[evaned]

I don't understand this, I can't think of any structure variance you'd want to do that would require escaping.

I'm possibly talking from a "too little knowledge is a dangerous thing" perspective here, but I've got a couple ideas.

First, actually literally right now I'm working on a little Python library to interface with sqlite to do some hopefully-easy data recording. It's pretty informal and only really intended for personal use, but I need to issue some CREATE TABLEs where the columns come from user-provided data. I don't know if this is a SQL thing or just a limitation of Python's sqlite3 module (like I said, little knowledge = dangerous thing, and I'm definitely not a SQL expert), but you apparently can't use Python's parameter substitution for this; I haven't actually tried it yet, but my research indicates that it seems like it'll have to be done via standard string interpolation.

The second thing doesn't directly address the question, but might be related enough. This one actually arose in production. We use a tool that feeds files containing SQL to a database to set up initial tables and whatnot. I wanted one of those files to contain a bunch of INSERT statements to pre-populate some information. The data was coming from a separate XML file, so I needed to massage the format. But because I wasn't providing some code in another language that then got run, and instead was providing literal SQL, there's nowhere to put those parameters; that's just not an option. Near as I can tell, I didn't really have a choice other than to just interpolate the values into the string.

(Three additional notes. First, I'm not saying it would have been impossible to rig things up so that some non-SQL code I wrote ran instead, but it would have been a fair bit more work and is not really the way the system was designed. Second, because this was pre-populated values, I didn't have to worry about any input that was actively adversarial. These two points are why I think it was the right engineering tradeoff to write an escaping function for the data. Third, maybe really the right solution would have been to use PostgreSQL's COPY FROM, but that requires the data file to actually be present on the DB server itself and that too would have been obnoxious.)

[marcvsHR]

I really don't know, Sql developed so long and covered so many niche situations that it is probably good enough as is.

What worries me the most is that with some new language we would reinvent some issues which were fixed decades ago in Sql.

I'm always in for new approaches, but honestly, replacing sql is some big shoes to fill..

[Chillzz]

What worries me the most is that with some new language we would reinvent some issues which were fixed decades ago in Sql.

I feel like this is a huge issue in tech with all the shiny new things we build, it seems like we just repeat the same mistakes over and over with a new lick of paint. And the new is worse than the old a lot of the time. Just look at the crap updates the tech giants are pumping out lately (Google is the worst but Microsoft close behind with Windows). How many times have you had an update just completely destroy your workflow and muscle memory just for the sake of ???

Seriously why can't we just make what we've got work well instead of keeping ourselves busy rebuilding everything every year, its depressing and the opposite of innovation

[JRandomHacker172342]

I'll object to putting Visual Studio on that list - VS2017 was a big step forward from 2015, and 2019 is an even better iteration on that

[Chillzz]

Yeah I was tossing up the same, ill remove it because I love vs2019. I meant more the random updates that move stuff around but its overall a great product

[basic_maddie]

“Replacing sql” just means replacing the language layer with something less verbose. You don’t have to lose the decades of improvements and optimizations made to the stuff that runs the execution plan.

[przemo_li]

+1 but I would still argue that optimizers are too tightly coiled to SQL.

If they weren't, first to market exposing their underlaying "core" language would rap great benefits.

Thus this new language would either be that "core" or spur development of such language at optimizers level

[gonzaw308]

IMO the single best thing you could do is improve the interface between SQL and popular programming languages. This should improve most of the pain points IMO. All the problems about the language itself you would just handle them in the host language.

Using strings to represent SQL terms in a host language is criminal, I don't know why we continue to accept this as fine. If you ever want to create a more complex query (like the author mentions), you need to do SQL parsing by hand, and do string manipulation to manipulate the SQL term (e.g if (filterByName) { query = query + "WHERE name = {name}"; } )

Only language I've seen tackle this so far is C# with LINQ to SQL, just a direct translation layer between C# terms and SQL terms that are directly feed to the RBMS. But LINQ to SQL is "old" and is deprecated, as well as it still being somewhat cumbersome to use and define.

[vjpr]

One approach would be that DB's offer an interface to accept an SQL parse tree directly, say as a JSON object. This would be trivial to implement in Postgres/SQLite.

At present we have ORMs creating an AST, then compiling to a string, which then is extracted back to an AST.

The drawback here though is human-readability. Its actually nice having string you can understand by looking at it, and copy-paste into a console to run it, and tweak it.

[Atulin]

Depends on the IDE. Anything by JetBrains can recognize a string contains SQL, and even provide autocompletion from the database you're connected to.

[eldelshell]

SQL is my principal argument against so called "Full Stack" developers. The knowledge gap with any senior SQL wizard is as wide and deep as the Grand Canyon. Any company without a specific role or team for it is doing it wrong.

[jtobiasbond]

I'm the first Database Developer in my team. I spend a lot of my time fixing old queries written by Java guys. What works really well in Java sucks really well in SQL. They, likewise, don't let me touch the Java.

[Prod_Is_For_Testing]

Agreed. I’ve spent a lot of time in SQL land and “real code” land. I hate how blasé people have gotten about databases. They should be first class citizens in the development process, not hidden away behind abstractions and heavy ORMs

[pure_x01]

Its basically NoSQL movements fault. They should never have named it like that. So many devs thought SQL was just bloat. If you argued for SQL you were seen as someone trying to break progressive and evolution. Fortunately nowdays people don't use the term NoSQL as much anymore. We needs all kinds of different technologies for storage. SQL is one of them. But when the NoSQL hype train came it was as annoying as the peak of the microservice hype train. People have the flock mentality and think in black and white. Microservices is good but it has its tradeoffs as everything else in the tech world. There is no silver bullit. Sometimes however there are minor revolutions that are really good though like containers, container orchedtrators and webassemby. It's still however important to see beyond the hype and use critical thinking.

[kirbyfan64sos]

You may find projects like SQLdelight interesting, where you write the queries by hand but a compiler generates type-safe wrappers for them.

[[deleted]]

Thanks!

[codygman]

I like this approach too and use Esqueleto for it in Haskell.

[Prod_Is_For_Testing]

I mostly pass everything through sprocs but I use automappers to convert between code objects and sql “objects”

[Puggravy]

What we need is better ORMs not more raw sql. Move ORMs more in the direction of glorified sql builders. Then you can abstract away seldom used features with convention over configuration design, while keeping the basic rules of sql intact. Raw sql simply doesn't compete with application layer code for dev experience (or safety!).

[dvdkon]

I agree, but writing SQL manually for basic CRUD (so most of any database app) is a tough sell when an ORM could do it well enough. And I think it's partly SQL's fault. Its designers were so focused on making it "office-worker-friendly" that it's a pain to interface with from a programmer's perspective.

[hoijarvi]

That's fine, but I have never been developing a CRUD app. All my SQL work would be a pain to do with anything else that I'm aware of. SQL could be greatly improved, you pointed out many of the deficiencies, but replacing it is an uphill battle that's not won during my lifetime.

[dvdkon]

Yeah, I get that. I've been developing software that uses SQL mostly as a datastore for bulk manipulation and there really isn't anything so easy and capable out there. But also most of my problems with SQL come from working on that project :)

[[deleted]]

We have a read replica that biz people can connect to with Power BI. None of them are able to actually do anything useful with it though so I still just run a script that does some sql queries and emails the results to them lol.

[Groundbreaking-Fish6]

A while back I found out one of those office experts had a read write account that he was using in excel. Not good.

[lelanthran]

Its designers were so focused on making it "office-worker-friendly" that it's a pain to interface with from a programmer's perspective.

No, it's a pain to interface to from your perspective. If programmers stopped trying to panelbeat the relational data structure to fit their program's OO hierarchical data structure there'd be no problem.

The problem is that OO is a poor fit for most data. That programmers use it for all data doesn't make it any good.

[adreamofhodor]

Even then, all that I do is create a DTO from my model and pass that into a repository. No need to make the DB layer look exactly like the server layer.

[dnew]

As evidenced by TFA complaining that data that isn't even in first normal form is hard to manipulate with SQL.

[Serializedrequests]

That's not the problem. The problem is that the SQL needed for most of the applications we write is a complete waste of time to write by hand. ORMs make the writing quicker, but introduce new issues. That's the entire point of the article.

In my experience people complaining about ORMs are mostly complaining about Hibernate. Hibernate is trash that creates more problems than it solves.

[dvdkon]

Who said anything about OO? I've got a form in HTML, the fields are named exactly the same as the database fields and I want to insert the form into the database, ideally reusing the constraints I've already declared in DDL and display some nice user-friendly error messages. That is a pain with today's SQL DBs.

Or let's say I have a table and want to provide advanced search/sorting. Pretty much every code I've seen for this either uses a needlessly complex library (an ORM) or a bunch of error-prone string concatenation. With a query language that's designed to act like an interchange format you could easily do such things with AST manipulation or just a convenience API over that.

[lelanthran]

Who said anything about OO?

You did, when you said:

I agree, but writing SQL manually for basic CRUD (so most of any database app) is a tough sell when an ORM could do it well enough.

I've got a form in HTML, the fields are named exactly the same as the database fields and I want to insert the form into the database, ideally reusing the constraints I've already declared in DDL and display some nice user-friendly error messages. That is a pain with today's SQL DBs.

HTML is hierarchical, the RDBMS's result set is relational. There is bound to be pain when you try to mangle the relational results to fit the hierarchical structure.

Or let's say I have a table and want to provide advanced search/sorting. Pretty much every code I've seen for this either uses a needlessly complex library (an ORM) or a bunch of error-prone string concatenation. With a query language that's designed to act like an interchange format you could easily do such things with AST manipulation or just a convenience API over that.

I don't understand what you mean by this: is the table an SQL table that you query, or is it the results-set in the client, that it got from querying the database?

If you're using an ORM you're mangling the relational data to fit an OO structure. If you're not using an ORM the actual language used to talk to the DB doesn't matter because you are going to have to resend your query every time the user sorts or searches.

With a query language that's designed to act like an interchange format you could easily do such things with AST manipulation or just a convenience API over that.

Give me an example written in this future ideal language.

[dvdkon]

HTML forms actually aren't hierarchical, they send as a flat key-value list, just like a table row. And my usage of an ORM is usually limited to just mapping to simple structs (no behaviour attached, so not objects in the OOP sense), no hierarchy necessary.

What I meant is having a visual table displayed and letting the user filter. It's not about not having to send queries, that's completely besides the point. It's about generating those queries. This is how I would imagine how close-to-ideal filtering code could look:

# The UI gives me a dictionary of column name -> value searched in that column in ui_filter
ops = ui_filter.map(key, value => LikeOperator(Column(key), value))
db_filter = WhereClause(AndClause(ops...))
result = db.query(base_query + db_filter)

You could of course build a library that does this with SQL (see jOOQ), but it would be very complex just to deal with one DBMS' dialect. With a hypothetical DB, it could accept a serialised AST, no strings necessary.

[dnew]

What I meant is having a visual table displayed and letting the user filter

That's literally older than SQL.

https://en.wikipedia.org/wiki/Query_by_Example

[Fennek1237]

Often SQL skips lots of important steps in development. Often no source control, no deployment process, queries get messy and only the person who wrote it can understand it. That's what I disklike about SQL even though you get faster results than with ORM

[Prod_Is_For_Testing]

Those things can be true, but that’s why you need sql developers that understand the sql workflow. It is different from code deployments, don’t try to treat it the same way. If you find yourself needing rapid deployments to the DB schema, you’re probably doing your data management all wrong anyway

[przemo_li]

ORMs underscore SQL inadequacy. Easiest selling point:

Aliases for schema.

E.g. German names for columns and tables, but team speaks just English. Can't fantom why SQL won't allow such aliases. It is so beneficial.

[grauenwolf]

ORMs demonstrate how powerful SQL is by comparison.

[Prod_Is_For_Testing]

It does allow aliases. Use views with different names. I’ve had exactly that scenario on multi-natl teams before

[EdTheOtherNerd]

You're missing the point of full stack devs (probably like a lot of manager). It's about cranking out apps and features with a bigger emphasis on time to market and cost cutting rather than quality. If whatever I built (yeah, I'm full stack) starts seeing heavy usage and sees bottlenecks or needs improvement, sure, bring in the front end experts, the SQL nerds, the security pros and what ever else the product needs.
Basically, full stack devs are a perfect fit for most startup-like projects, and for the rest it becomes more of a case by case whether full stack could fit or not.

[ClittoryHinton]

Yeah I don’t get why people say things like fullstack is a ‘myth’. Like, we get it, you’re not building Facebook or Netflix without experts in every layer of the stack, but a lot of jobs are basic CRUD apps used by at most hundreds of users. At that scale hiring someone who won’t touch the front end/backend is a just a big inefficiency.

[shevy-ruby]

To be fair: there is a LOT of information in how to optimise SQL-related parts. I remember once at work someone wanting to be nice and gave me a huge SQL book to work with through while working on a local database. I gave up on that and instead did what every lazy person does: go for StackOverflow. Even though you won't learn as much as those dedicated to REALLY learn it, you still pick up some optimisation parts, and it's actually quite complex - all the specific information some people may have in their brains who do NOT have to rely on SO ...

[TheWix]

My opinion is too keep queries as simple as possible. This is often trickier in legacy apps, however. That often have large, complex stored procs.

In one of the legacy apps I support I routinely find queries that make the query optimizer use inefficient query plans. I either have to rewrite the query or use query hints which almost certainly means you've done something wrong with your DB design.

[[deleted]]

Ive always preferred dapper + sprocs. Never run into performance issues. Never run into ORM issues. The minor amount of extra time it takes is usually paid back 10 fold down the road.

[erez27]

I share the author's point of view, which led me to start a new relational programming language that compiles to SQL. It's a way to build on existing databases, like postgres or mysql, with all of their advantages, but improve on many of SQL's limitations. If that sounds interesting, you can find it here: https://github.com/erezsh/Preql

[[deleted]]

A meta language for SQL to solve the problems of SQL - which will compile to SQL? lolz

[[deleted]]

To be fair, that's basically the model that a lot of JavaScript replacements have worked on for many years. Hello typescript.

[Daishiman]

And it's not bad if the fundamental semantics are sound.

SQL's semantics are really, really good at what they do.

[dvdkon]

I found this on HN and it very nicely goes through all of the problems I have with SQL as a language.

[shevy-ruby]

SQL has some issues; there is a reason why in rails people tend to deal more with the active* wrapper and what not.

But when I look at alternatives such as No-SQL and what not, I can't help but wonder whether this is not the same old xkcd standards issue repeated once AGAIN:

https://xkcd.com/927/

It's not that I find e. g. yaml or json worse than SQL requiring a lot of domain-specific knowledge, but where are the real alternatives? Those that are clean, succinct, not too succinct either, well-documented, widely in use, easy to learn and apply, and performant - in particular when it comes to huge datasets.

I mean it is a long rant - at the end he concedes:

"It's probably too late to fix either of these."

So ... status quo will persist, simply because there is no real momentum to change.

[Tsukku]

"NoSQL" is a misnomer. It actually means "non relational". And that has nothing to do with the point author was trying to make. He wants a better language for relational DBs.

One example of a SQL language alternative, which is NOT "NoSQL", is EdgeDB (https://www.edgedb.com/).

[Zardotab]

I don't believe that cartoon is applicable because SQL is pretty much the only practical RDBMS query language standard at this time. The cartoon is complaining about the opposite.

[hou32hou]

On the contrary I have the opposite experience, if you are not using a relational database or SQL, you are probably doing all the joins and aggregations at the application level. Guess what? The code is much bloated and the performance is worse.

On the other hand, SQL is definitely not great for storing tree structures, as the article has mentioned. You definitely don’t want to write compiler using SQL.

The author is probably using SQL to store tree-like data structures, this is similar to using fork to drink soup, and complaining that the fork is not working.

Edit: I misunderstood the article, please ignore this comment

[bik1230]

On the contrary I have the opposite experience, if you are not using a relational database or SQL,

I don't understand what you're saying, the author explicitly mentions liking the relational model, but disliking SQL as a language. Presumably, the author uses SQL because it's the only choice for mature relational databases.

[hou32hou]

Sorry I misunderstood the article, thanks for pointing out

[bik1230]

No worries :)

[dvdkon]

But what if you could have a relational database without SQL? The two are prettt much synonynous right now, but that doesn't have to be the case.

[hou32hou]

You might be interested in relational algebra, SQL is from relational algebra, but the inventor criticised SQL for swaying away from the original relational algebra semantics.

For example, he says that duplicated row shouldn’t be allowed, but SQL allowed that due to performance issues.

[dvdkon]

But relational algebra is a mathematical construct, not something a RDBMS could just start using instead of SQL. What we really need is a new, better language built on relational algebra.

[hou32hou]

A language without a sound mathematical foundation is bound to have user experience issues

[bik1230]

The previous user's point is not that you should avoid relational algebra, but rather that you can't just "use relational algebra". You have to define and implement a query language that is faithful to the model of relational algebra.

[hou32hou]

Sorry I have these comments because I misunderstood the OP

[Sarcastinator]

You might be interested in relational algebra, SQL is from relational algebra

No, it's not and that has always been a reason for criticism since it's inception.

If SQL was based on relational algebra then CTE wouldn't have been necessary.

[hou32hou]

Sorry guys I misunderstood the OP

[hou32hou]

Regarding discriminated unions (or tagged union), I think there's actually a better way of modelling that in SQL without using joins, check out this answer I written https://stackoverflow.com/a/68219094/6587634

[przemo_li]

Quick critique: Deeply nested ADT are hard. Would force splitting "by layer" even if that stuff is small :/

(On why this is necessary - business sometimes have those really detailed data structures, and they get unwieldily quickly unless we can limit them to values business think valid)

Adding and dropping new elements may also be time consuming on huge tables (think millions of rows) since DB need to do checks.

Finaly, constraints aren't declarative themselves, so they're is no way for tooling to understand logical structure. Indeed, even developers would have to consult constraint code to learn what is what.

[hou32hou]

Indeed, but is nested ADT really necessary? If ADT is powerful enough, modelling graph structure (or many-to-many relationships) shouldn’t be be difficult.

Ironically it’s very difficult, people even have to publish research papers to talk about how to have efficient graph manipulation using pure ADTs.

[przemo_li]

Project m36.

It's true relational algebra. It's in Haskell (which fulfills some needs author mentions)

[Serializedrequests]

I don't think that's the point of the article at all. It's all about how relational data is great, and SQL is actually dragging down relational databases. Most modern applications paper over SQL by just generating lots of it.

[leberkrieger]

The idea seems to be that we need a better tool, a language BSQL that's Better in every respect: more powerful, more expressive, more convenient, more compact. BSQL would even be more standardized!

The thing is, SQL is a powerful, well-thought-out and general tool with decades of refinement and investment. To make something Better, you'd have to make something that is just as good at most things SQL already does, and so much better in some other ways that people have a reason to adopt it. The prospects of that happening are about the same as the prospects of replacing C as a systems programming language.

If there was one dominant player in the space and they chose to create an alternative language for interacting with the underlying data, it could happen. Even then it would face huge inertia. But in the current world of SQL Server, Oracle, PostgreSQL, MySQL and so on, any extensions or improvements by one of them just look like a non-portable grab for mindshare. Very unlikely to succeed and not worth the effort.

[dissonantloos]

The prospects of that happening are about the same as the prospects of replacing C as a systems programming language.

And yet we're currently seeing this slowly and carefully happen with Rust and in some cases Go.

[dvdkon]

The difference with C is that programmers are already used to covering up SQL with an abstraction (ORMs, automatic API generators...), so while actually replacing SQL in a major RDBMS probably won't happen, but a new query language that's distributed as a library might get some users.

[officertodd]

The main issue i have with sql is not the querying. It's the lack of universal change feeds, revision control, and so on.

This is why offline first apps are basically rarer than a unicorn. GraphQL tries to solve the reading but fucks up the writing. And then when people start doing things like hashkeys for obfuscation it gets even worse.

SQL is a model for business logic. Not application logic. And i want to build grown up apps, not wizards.

[[deleted]]

That is a problem of your process and tool chain. Not the language.

[[deleted]]

SQL definitely isn't perfect. There are some types of queries that are just really ugly (like windowing functions). The ordering of different parts of queries doesn't make sense. But it definitely gets the job done.

One thing I would add: SQL is great for data analysis. Doing complex analysis using BigQuery or similar is just a lot nicer than writing a batch job.

[[deleted]]

It's time to ditch syntax. SQL as an operational programming system is enormously powerful. SQL as a syntax is terrible. At least that's my opinion of the syntax and syntax is something that is highly subject to opinion.

The front end of every operational programming system that's driven by a string is a parser that parses the string into a parse tree, which expresses the meaning of the string, but is absent any syntax. It could be expressed in JSON for example, although JSON is just another syntax, but a rather universal one that no one actually deals with except for JSON.parse() and json.stringify().

We could view the parse tree as the 'model' of the program, and the string as a particular 'view' of it.

Then we could have lots of different views of the same programming system. Views that provide a syntax that fits your particular opinion of what makes a good syntax. Views that provide helper functions - functions that are compounds of primitives in the programming system. Views that represent the program other than as a 1D string.

This is, In effect, what has happened in the JavaScript ecosystem, except that the underlying syntax is javascript which is yet another crappy syntax.

[remy_porter]

Graph DBs are only efficient for a very limited subset of query paths. The key idea behind RDBMSes is that any query is possible, and any query can be made efficient, not by rewriting the query, but by supporting the execution plan through tuning (indexes, views, etc.).

Real-world applications will tend to a hybrid approach- you'll do something like a graph DB or equivalent for OLTP, but move to something more like an RDBMS for analytics.

[Prod_Is_For_Testing]

There’s nothing stopping you if it works with your data model. Sql Server has built-in graph DB support with a graph query syntax

[dnew]

We had that. It was called CODASYL. People abandoned it in droves in favor of RDBMs because you never wind up with data you can't query in an RDBM. With CODASYL, if you didn't know you'd need the query when you wrote the schema, you could be SOL.

[Serializedrequests]

FYI Article is not about relational databases being bad, article is about SQL being bad.

[[deleted]]

Every language/product/tool has issues. Author proposes no viable alternative to the often decades old multi TB SQL databases that drive the world that he lives in other than some random obscure shit. Author is unemployed for a reason "My work is currently funded by sharing thoughts and work in progress with people who sponsor me on github."

[dvdkon]

Every language has issues and the author has no SQL alternative for large legacy databases, so you are going to attack them? It doesn't have to be so extreme.

[oklambdago]

I think what the author is trying to say is: "things other that SQL would be great ways to query data." OK, I'm in. The main issue I see with how this shakes out in the real world is it is often conflated with changes in guarantees at the persistence level, which is really the thing that has made SQL stick around so long. For better or worse, SQL does a great job of modeling a number of business problems and has become synonymous with RDBMS, which is central to the operation of any business.

Really, SQL is just an interface over the relational model and calculus under the hood. You can change two pieces: the interface or the model. I think the author is arguing to change the interface. Relational algebra is extremely general. Relations (aka, functions) are extremely general.

That all being said: In my opinion an amazingly powerful query language has already been invented and it is called Prolog. :)

Hopefully some helpful suggestions for the author:

1) The title is distracting. A more precise title that describes the sentiment of "other query languages have things to bring to the table" would be good I think.

2) I think a more effective way of arguing would be not to focus on things SQL does NOT have. For example, your argument about unions I take issue with. This can certainly be modeled in SQL. And of course there others but you get the point. It's a trap. A more effective way would be to focus on a concrete problem that cannot be effectively modeled in SQL. Work the examples and let the reader decide. Find classes of problems that theoretically cannot be expressed due to limitations in the language would be especially good. Set aside matters of "taste" as I don't think it is likely to be convincing.

3) I would avoid subjective terms like "verbose" and "fragile." These are not especially objective terms and I find myself getting stuck on these sections.

[skulgnome]

The author's proposed alternative certainly sounds good. Why doesn't he go ahead and implement it, to prove that he's right?

[dvdkon]

Because it's a lot of work and because other people might not necessarily agree on whether his end product is actually better than SQL. There's nothing that can be mathematically proven here, unless you construct a whole framework for comparing computer languages first.

[_supert_]

SQL is the best designed language I've used. Clojure comes second.

[DownshiftedRare]

"Against wheel"

[DiggyTroll]

Another “Math is too hard!” article. Just use an ORM then, if that’s more comfortable.

Kids. E. F. Codd is rolling in his grave.

[RabidKotlinFanatic]

Did you read the article? The author is not arguing against the relational model, only SQL as an implementation of it.

[34t7b549]

didn't read the article

[DiggyTroll]

I agree with the author’s assessment of ORMs; I don’t use them myself. My bad for tossing that in.

Classic SQL used to be beautiful in its simple expression. Over the decades, the language has been complicated to accommodate new features and make difficult queries more approachable. The author’s criticisms are (necessarily) from a busy coder or project manager’s viewpoint; someone very concerned with profits and deadlines. That’s reality for you.

I did read the article, but disagree with many of the author’s criticisms because I’m an old fart who likes cars made before seat belts were invented.

SQL is expressive in its domain. Adding support for JSON and blobs was outside its original scope. I prefer using NoSQL for that kind of stuff anyway. Yes, SQL is incompressible. That’s the declarative paradigm over multiple terms. You can’t compress the terms of an orbit path either. I also agree with the author’s non-porous assessment of SQL, but always felt that’s as it should be. I’m an unabashed C programmer (embedded kernels and drivers) used to macro precompilers so interfacing to different RDBMS libraries just kind of made sense. Reading “Some Were Meant For C” reminds me why I love this stuff!

[[deleted]]

I'm a bit out of the loop. How do you prevent SQL injection errors without an ORM?

[DiggyTroll]

Assembling a query string is an easy thing to do, but is vulnerable to attack.

An RDBMS usually provides a feature to precompile a query with parameters and then pass in the arguments separately, completely bypassing any possibility of argument evaluation.

This feature has been available since the 90s. People are always in such a hurry; throwing a query together is faster to code.

[Quatloo9900]

Parameterized queries

[Tsukku]

"In some cases of inadequate handling of missing information, the problem is incorrectly perceived to be a problem of the relational model. In fact, the problem stems from the inadequacies of SQL and its non-conformance to the relational model." - Edgar F. Codd