Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We Can Do Better Than SQL

edgedb.com

Post reply on HN
Print view View original

391–400 of 466 posts

Re: We Can Do Better Than SQL

#391

Post by nightski »

gboss wrote: post #301
goto11 wrote: post #291

Earlier quoted context omitted.

> SQL is messy because describing the underlying data relationships are messy. No, the relational model is beautiful and consistent! SQL is messy because the syntax is not consistent and elegantly composable. It could have those properties and still present the same underlying data relationships. See Linq in C# as an example for how a more composable query syntax can expose the same data model. For example in Linq yo…

Slightly tangential but I really like Linq syntax. The only problem I have with it is that it is really hard to debug if there is a logic error. I often see developers write linq find out the record set they get back is incorrect and then break up the linq query to a nested if clause to get what they want.

Yeah I feel like that happens whenever you have a mapping from one language to another. Eventually you learn the intricacies of the transformation. There are very few situations where the Linq I write does not translate into the query I expect any more. But that took time to learn.

The only criticism I have of Linq is that it is a more general language targeting different back-ends including plain old objects. If Linq did not allow things that do not make sense in SQL this would be a little less jarring.

I also wish it supported full outer joins, unions, and window functions.

Re: We Can Do Better Than SQL

#392

Post by njharman »

013a wrote: post #336
tqi wrote: post #84

It's pretty arrogant to complain about the syntax being inconsistent across versions and databases and then present your own weird offshoot, as if every other version wasn't introduced for the exact same reason with the exact same lofty delusions of grandeur... SQL is messy because describing the underlying data relationships are messy. The orthogonality example is a great illustration of this. What exactly should th…

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

> db.users.find({ foo: "bar" })

I don't know MongoDB query language, but gah! that looks horrible. It uses three different syntaxes; dot notation, curlies/brackets and colon key value. Full of punctuation and doesn't read like english.

There is no distinction between noun "users" and verb "find". There's extraneous "db". does foo: "bar" mean equal or is it find() that determines the operator, maybe combo of both? how do I do other operations.

.Only if you are familiar with programing language that has that same syntax does any of it make sense. Otoh even educated non-programmers are gonna be able to read the SQL as SELECT "these things" FROM "this table" WHERE "these conditions are true".

Re: We Can Do Better Than SQL

#393

Post by zvrba »

isatty wrote: post #170
seer wrote: post #129

I for one would welcome a new alternative to sql. It might not be _this_ alternative, but why not try. SQL is very hard to learn properly, with all of its gotchas and inconsistencies. There are running jokes for noobs truncating their tables due to forgetting a where clause. I’ve seen junior devs crying in tears and throwing their mice just because they needed to debug / optimise a complex query. The mare existence o…

> SQL is very hard to learn properly, with all of its gotchas and inconsistencies. I don't understand why though? I've been using SQL (Postgres for the most part but with a smattering of MySQL thrown in) for around 8(?) years, which isn't much in the grand scheme of things but I have not had anything that couldn't be resolved. I've written small straightforward queries to over 200 loc and never had a problem understa…

> In fact, ORMs have been a massive headache because I can think in SQL but not in whatever the creator of the ORM was thinking in.

Yes, fully agree on ORMs. They DO have one nice feature though: simple CRUD operations are way less verbose than constructing SQL statements.

What we lack is a better integration between the host language and the databse. Constructing a prepared statement from a string, setting parameters, executing, fetching rows from the result set and mapping back to fields... all is a major, repetitive PITA.

And yes, I find it easy to think in SQL and often wonder WTH an ORM is going to generate. Just recently I improved performance of an application by going from ORM to SQL; first I reduced number of round-trips (ORM/efcore first wants you to fetch an entity before you can update it), second, I batched updates into a single session/transaction. Win! :) [Oh, and don't get me started ranting about ORM and transactions.]

Re: We Can Do Better Than SQL

#394

Post by moron4hire »

throw_m239339 wrote: post #55
moron4hire wrote: post #16

I've always wondered if a newer language could be designed with ANSI SQL as a transpilation target, or each of the vendor SQLs as targets. Optimization of queries would be a huge problem, but it always seemed like the only way it would be possible to break out of the SQL hegemony, i.e. first transpile, then start developing native support in the open source databases, then pressure the proprietary databases to adopt…

That's what frameworks like Hibernate or Doctrine do, they have their own object oriented query language that compiles to SQL.

Well, that's an object oriented design, and it's not really a full language in that it has its own syntax. I'm talking about a relational language with its own syntax.

Re: We Can Do Better Than SQL

#395

Post by thingsilearned »

I've had similar thoughts to the title, but my ideas were more around improving the ease of use/writing.

1. A cleaner universal more natural syntax for analytics: I love writing python as it is to me such a cleaner syntax than C or Java. We could do the same for SQL and make something that feels more natural. Turning a common query like

> SELECT count(*), TO_CHAR(created_at, 'YYYY-MM-DD') FROM Accounts GROUP BY TO_CHAR(created_at, 'YYYY-MM-DD') ORDER BY TO_CHAR(created_at, 'YYYY-MM-DD');

into something much more natural like

> count by Day(Accounts.created_at)

2. A Visual SQL: for analytics it's so much faster to query and explore visually. Building queries visually means you don't make common typo or syntax or structure errors, joins happen smoothly, you can browse the data as you build, you don't need to google for syntax (what's that date function again?), and it works across dialects and databases. We've built and launched this a few months ago at Chartio https://chartio.com/blog/why-we-made-sql-visual-and-how-we-f...

Re: We Can Do Better Than SQL

#396

Post by doubletgl »

njharman wrote: post #392
013a wrote: post #336

Earlier quoted context omitted.

A very simple, basic SQL query would be something like "select * from users where foo=bar;" Already, we're introducing a weird inversion of syntax that, in my experience, trips up people learning it: data in SQL is stored as "rows" with "columns" inside "tables". More formally, we've got a hierarchical relationship where Tables > Rows > Columns, yet we write the query as Columns > Table > Rows. There are far more con…

> db.users.find({ foo: "bar" }) I don't know MongoDB query language, but gah! that looks horrible. It uses three different syntaxes; dot notation, curlies/brackets and colon key value. Full of punctuation and doesn't read like english. There is no distinction between noun "users" and verb "find". There's extraneous "db". does foo: "bar" mean equal or is it find() that determines the operator, maybe combo of both? how…

> Only if you are familiar with programing language that has that same syntax does any of it make sense.

I'd argue that most relational DB users are familiar with a programming language, and therefore most likely familiar with the C-style syntax. It's better to build on something that most of the potentials users are familiar with already.

> There is no distinction between noun "users" and verb "find".

There is no such distinction in natural language either (if you see words purely as sequences of characters), you have to know what is what and infer it from the context.

> even educated non-programmers are gonna be able to read the SQL as SELECT "these things" FROM "this table" WHERE "these conditions are true".

Yeah SQL looks a bit more like natural language at first glance, but that's about it. That familiarity is a false friend, it doesn't really help with the learning curve.

This kind of thinking reminds me of the ruby community trend a decade ago when DSLs were created to look beautiful and like written language. It's useless and confusing for long-term, practical purposes. Same with BDD style testing languages. The promise that non-technical people will feel right at home and can start contributing rarely lives up to reality.

Re: We Can Do Better Than SQL

#397

Post by waheoo »

no-s wrote: post #384
waheoo wrote: post #31

Earlier quoted context omitted.

You can pry SQL out of my cold dead hands. Its just not that bad.

>>You can pry SQL out of my cold dead hands. Its just not that bad. I often joke that SQL is the COBOL of the 21st century. HHOS. There's worse things...e.g. COBOL. Actually it's very difficult to deny the empirically discernible utility of relational databases and SQL. SQLite, for example.

I'm alright with that.

I think the problem is that developers love to abstract everything. And with the database often becoming a god object it's often targeted for abstraction.

The problem is, querying data is a complex problem, complicated enough to require a query language.

So the developer goes off to abstract the database for their needs, a helper table object here, a helper row object there and eventually you start to see an Orm appear.

Developers need to be told to stop this behavior.

The abstraction is the thing you are representing in the database, not the database.

Your models should use plain SQL queries to execute behavior.

If you must, setup some helpers to do very basic crud operations, but as soon as you need to really alter a where or a select, drop to SQL, use the language as intended and watch your code suddenly become modular, readable and maintainable.

Yes, this means you will need to write SQL, yes this means you will write a lot of select and where statements, no this is not code duplication, stop freaking out about non problems.

I swear to god DRY is the source of and solution to all developer problems.

Re: We Can Do Better Than SQL

#398

Post by achr2 »

wtetzner wrote: post #390
achr2 wrote: post #340

Earlier quoted context omitted.

I disagree, the relational model is very incongruous with the object model that nearly all LOB applications use. Which is where 99% of the usage issues lie.

That doesn't make the relation model bad, it just means there's an impedance mismatch. FWIW, I find the relational model to be much nicer than typical object models. Even in Java, which I write every day at work, I've found it to be much clearer to use immutable objects representing records. Not just for interacting with the database, but just for handling information in general. Of course, it would be extremely pain…

I agree that the mismatch is not a direct failing of SQL or the relational model - but we continue to use it without adopting a better approach or developing a common abstraction layer. With all of the syntax growth, SQL could certainly have a join syntax that understands object composition and returns structured data.

Re: We Can Do Better Than SQL

#399

Post by Risord »

sanderjd wrote: post #354
mufufu wrote: post #310

Earlier quoted context omitted.

> It should be possible for an amateur to quickly write an SQL validator as a starting project I think the point he is trying to make here is the same as the post was making concerning orthogonality. Having a smaller set of special syntax, and therefore an easier validator to write, means easier queries to write for the user. I don’t think he was implying that everyone who makes use of the language should know how to…

The syntax is not the interesting part for programming languages either. Programming languages now have better semantics - things like runtimes, concurrency, data encapsulation, etc. - in addition to better syntax. SQL is not a programming language, its semantics boil down to the relational model. Don't get me wrong, there is room for improvement in the syntax, I have plenty of gripes with it, I just don't agree that…

Indeed semantics is what matter but I think for example lack of composability is semantic problem too.

Ability to manage persistency and correctness of SQL engines is very usefull while language interface not so much.

Post reply on HN