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

441–450 of 466 posts

Re: We Can Do Better Than SQL

#441

Post by throwaway_pdp09 »

okaleniuk wrote: post #438
throwaway_pdp09 wrote: post #108

Earlier quoted context omitted.

> As long as there's nothing valuable in the technology itself You're assuming there's nothing valuable. I'd say there is. Whether that's enough to displace SQL I really doubt.

Maybe there is. I didn't try it. But it's written rather explicitly "OK, so we have highlighted the shortcomings of SQL. Why do they matter? It’s all about ergonomics." That's what drove me off.

> "...It’s all about ergonomics." That's what drove me off.

I don't understand. Their critique seems eminently reasonable, what else should it have been about that would have not driven you away? (thanks for the answer, upvoted, it lets me try to understand your position).

Re: We Can Do Better Than SQL

#442

Post by IHasFingers »

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

Earlier quoted context omitted.

> 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…

Why would you want your query language to read like English? Most people don't speak English.

I don't think SQL would be better if it read like Mandarin.

Re: We Can Do Better Than SQL

#443

Post by okaleniuk »

throwaway_pdp09 wrote: post #441
okaleniuk wrote: post #438

Earlier quoted context omitted.

Maybe there is. I didn't try it. But it's written rather explicitly "OK, so we have highlighted the shortcomings of SQL. Why do they matter? It’s all about ergonomics." That's what drove me off.

> "...It’s all about ergonomics." That's what drove me off. I don't understand. Their critique seems eminently reasonable, what else should it have been about that would have not driven you away? (thanks for the answer, upvoted, it lets me try to understand your position).

For instance, we choose Riak+LevelDB some 8 years ago as our data store. It doesn't support SQL but it's fast and easily scalable. And free. I'm not sure if we could achieve the same speed and fault tolerance with any SQL solution available at that point. So the deal is, you give up your time invested in learning SQL and get some advantages in return. This is reasonable.

But if it's only about language, no additional perks, then it just isn't worth investing your time.

If continue the parallel with programming languages, there are tons of C-killers nobody knows about. I think, roughly every third programmer in the world tried to write more ergonomical C at some point in their live. And there is Rust. Which is not about ergonomics really but about memory safety combined with comparable performance. No more buffer overflows, no more Heartbleed. People see what they are trading their time on Earth for and the language is getting traction because of that.

This is, of course, only my personal opinion but languages are just thin interfaces over technologies.

Re: We Can Do Better Than SQL

#444

Post by ComodoHacker »

achr2 wrote: post #338
jimsparkman wrote: post #315

Earlier quoted context omitted.

WITH (CTEs) make queries so much more readable and digestible. As a programmer who now does data and SQL, I latched on to these as soon as I found I could reduce repetition in a query with them.

CTEs do not get cached though, so they are actually quite bad for repetition without also using a temp table.

Depends on DBMS and version. Some are smart enough to pipeline/tie or materialize it internally.

Re: We Can Do Better Than SQL

#445

Post by scarface74 »

nightski wrote: post #391
gboss wrote: post #301

Earlier quoted context omitted.

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 Lin…

I was amazed the first time I used the MongoLinq driver. It makes sense intuitively, but the idea that you can use the same Linq expression and it will be translated to either Sql or MongoQuery based on the provider you send it to was amazing.

I was able to hire a four or five contractors who never used Mongo just by requiring Entity Framework/Linq experience and less than 4 hours of training.

Re: We Can Do Better Than SQL

#446

Post by scarface74 »

nine_k wrote: post #412
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.

It's the problem with the object model. Yes, I think ORMs are an anti-pattern, ActiveRecord-style especially.

And then you end up inventing your own ORM and “helpers” because eventually the results end up in objects.

I do hate most ORMs. The only oneS I like are Linq based ORMs. The “ORM” is actually well integrated into the language.

You might as well use something like Dapper.

But yes agreed about ActiveRecord.

Re: We Can Do Better Than SQL

#447

Post by scarface74 »

nicoburns wrote: post #218
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?

Completely agree. For example, why isn't there functionality to define aliases for complex expressions and then reuse those through a query. Simple query-local SQL functions would be nice too. I'd love to see a "SQL-like" language that compiles down to SQL itself, much like Babel or TypeScript in the JavaScript world. I think the tricky thing is that there is no single SQL target.

Linq

Re: We Can Do Better Than SQL

#448

Post by parliament32 »

nicoburns wrote: post #218
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?

Completely agree. For example, why isn't there functionality to define aliases for complex expressions and then reuse those through a query. Simple query-local SQL functions would be nice too. I'd love to see a "SQL-like" language that compiles down to SQL itself, much like Babel or TypeScript in the JavaScript world. I think the tricky thing is that there is no single SQL target.

>functionality to define aliases for complex expressions and then reuse those through a query

What's an example of what you're trying to do? I think views, user-defined functions, routines, and select aliases would cover all the bases...

Re: We Can Do Better Than SQL

#449

Post by kevincox »

jeltz wrote: post #255
smabie wrote: post #140

Earlier quoted context omitted.

Do you love SQL, or do you love relational algebra? Because actual SQL, the language, is pretty shitty. Perhaps the best querying language I've ever used is Q-SQL, integrated into kdb+/q. Unlike SQL, it's actually part of the language (q/k) and, most importantly, it's modular and more expressive than SQL. If you're interested in how we can do a lot better than sending strings to remote databases using an inexpressive…

Not parent poster but I love relational algebra. But so far I have yet to use an alternative to SQL which is less bad. Most of them seem to be designed by people who do not understand SQL.

I agree with you, I haven't found an alternative that is less bad. But that doesn't mean that I like SQL. It is so inconsistent and uncomposible, with too many awkward ways to do different things.

I love the idea of a functional algebra for querying a database, and while SQL is acceptable, it is far from great in my opinion.

Re: We Can Do Better Than SQL

#450

Post by throwaway_pdp09 »

okaleniuk wrote: post #443
throwaway_pdp09 wrote: post #441

Earlier quoted context omitted.

> "...It’s all about ergonomics." That's what drove me off. I don't understand. Their critique seems eminently reasonable, what else should it have been about that would have not driven you away? (thanks for the answer, upvoted, it lets me try to understand your position).

For instance, we choose Riak+LevelDB some 8 years ago as our data store. It doesn't support SQL but it's fast and easily scalable. And free. I'm not sure if we could achieve the same speed and fault tolerance with any SQL solution available at that point. So the deal is, you give up your time invested in learning SQL and get some advantages in return. This is reasonable. But if it's only about language, no additional…

With respect, I think you're missing a lot. Sit with an expert SQL guy and you'll learn a great deal. Maybe not enough to change your mind but certainly enough to realise you're blocking out a really valuable technology.

> but languages are just thin interfaces over technologies

No. Not at all. SQL is derived from a mathematical basis. The principle came first, then the language and tech together developed to fulfil it.

Post reply on HN