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

161–170 of 466 posts

Re: We Can Do Better Than SQL

#161

Post by Wandfarbe »

I'm not doing SQL every day but i have rarely any issues with it.

Do we really need to do better than SQL? I don't think so and i also don't think that the chosen new syntax is better.

At the end of the day, most critical is not the language but understanding how it works to optimize indezes etc. If you are only able to write simple SQL because you are not good in SQL/Databases, you will not optimize your Database independently from the language.

If you are good in SQL/Databases, you (or at least i) do not care about syntax details; You just look it up, and get acquainted to your specific underlying Database.

Re: We Can Do Better Than SQL

#162

Post by iddan »

quickthrower2 wrote: post #120
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…

I was hoping for something more left field myself. If SQL is based on tables, what about a QL based on relations only. Columns of data that are related, the "TABLE" implementation detail doesn't need to factor into it.

This is what we are trying to do with Cayley https://github.com/cayleygraph/cayley

Re: We Can Do Better Than SQL

#163

Post by quietbritishjim »

AmericanChopper wrote: post #75
GeneralMayhem wrote: post #68

Earlier quoted context omitted.

Not disagreeing with your point (if purist language nerds had their way over practicality, we'd all be writing Haskell and Prolog) but most of your nice-to-haves strike me as properties of the database engine, not SQL itself. Predictable performance - this will always be not only implementation-dependent but data-dependent as well. In order to know whether a join will be efficient or not, you need to know things like…

> Predictable performance - this will always be not only implementation-dependent but data-dependent as well This immediately jumped out at me from the parent comment. It would be entirely possible to implement a query language where you specify a plan for your query. But then you’d immediately lose the “better than SQL” competition, because your complexity and maintainability problems would skyrocket. I’ve had to de…

I've had the opposite problem. In a system I've been working on a lot, I know exactly what indices I want used in what order to read the data. Admittedly the database often figures that out first time, but sometimes it doesn't, then I have to go through an infuriating process of changing parameters or tweaking the query into a mathematically equivalent form until it guesses what I want. In one case I was even forced to write a procedural loop in PL/pgSQL (yes, I'm fully aware this is an antipattern).

I don't want to give hints to the optimiser. I want to specify precisely how the data will be read and joined.

I appreciate this is this is the exception rather than the rule compared to how most developers would prefer to work. And this system is a bit unusual in that it's using a database for passing messages, which it isn't well suited for (especially not the way they're storing the messages.)

Re: We Can Do Better Than SQL

#164

Post by oxfordmale »

EdgeSQL is no better than the SQL out there, and is arguably much worse as it introduces yet another version of SQL. However, in the end EdgeSQL will only succeed if it has a better query optimiser than Postgres, SQL Server and Oracle. That requires a significant amount of investment and somehow I can't see this happening.

Re: We Can Do Better Than SQL

#165

Post by gorgoiler »

I often find SQL is extremely good for explaining what you are trying to do.

It is of course a declarative language, but more than that it does what a good language should do: explain in both directions.

Languages need to tell the machine what to do, and to tell the person reading the code what it was the original author was supposed to be doing. Many bugs happen when the two don’t match up, and the maintainer is often not the person who wrote the original code.

Well written and handwritten SQL is some of the least commented code I’ve seen because it doesn’t need comments — it is self explanatory.

Re: We Can Do Better Than SQL

#166

Post by sozy777 »

Akronymus wrote: post #142
bjo590 wrote: post #93

Am I the only full stack dev that likes SQL? SQL is an incredibly expressive and flexible way to read, store, and update data. It's ubiquitous, so the SQL skills I learned six jobs and three industries ago are still relevant and useful to me today. Relational Databases and SQL are heavy lifters that I often relay upon to build projects and get things done.

At work we almost exclusively use pure stored procedures[1] and everything is normalized very well. It is an absolute joy to write SQL, because of how terse it is while still being very readable. Trying to implement business rules about data relations outside of the DB is a nightmare. [1] We use dynamic SQL within stored procedures for pivots.

You lose source control on your procedures. How you deal with that?

Re: We Can Do Better Than SQL

#167

Post by dragonwriter »

sozy777 wrote: post #166
Akronymus wrote: post #142

Earlier quoted context omitted.

At work we almost exclusively use pure stored procedures[1] and everything is normalized very well. It is an absolute joy to write SQL, because of how terse it is while still being very readable. Trying to implement business rules about data relations outside of the DB is a nightmare. [1] We use dynamic SQL within stored procedures for pivots.

You lose source control on your procedures. How you deal with that?

> You lose source control on your procedures

Why would you do that?

Re: We Can Do Better Than SQL

#168

Post by quickthrower2 »

tsimionescu wrote: post #147
quickthrower2 wrote: post #122

Earlier quoted context omitted.

I love SQL. I'd love someone to make it better for complex queries. Have you seen the enterprise SQL monstrosities. Why do we have ORMs if SQL is perfect?

We have ORMs because our programming languages object models are not relational, they are hierarchical - from C to Haskell, everyone goes for highly non-relational data representations. So, when we interact with a relational DB we need some kind of layer to map between the world of relations in the DB and the world of objects in our program.

Correct but I didn’t explain well. I mean the SQL generation is left to the ORM and I think that’s no accident.

Re: We Can Do Better Than SQL

#170

Post by isatty »

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 understanding it if you read it slowly/broke it down into smaller queries.

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. Those giant queries that I was talking about - there's no way to represent them in ORM form.

SQL works in a language agnostic way, you can explain analyze your SQL queries and run it through whatever medium you prefer. Typical experience with an ORM goes like so:

1. Lets use an ORM because it'll be easier

2. It's not actually easier and it's a complex mess now, but let's stick with it anyway

3. Figure out a way to log the queries that the ORM made up for you/printf it

4. Run that through EXPLAIN ANALYZE

5. Can't make the ORM do that, file a bug report that'll be buried

6. Use native query while you wait

7. Tech debt etc;

Post reply on HN