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

Against SQL

scattered-thoughts.net

Post reply on HN
Print view View original

341–350 of 354 posts

Re: Against SQL

#341

Post by aliasEli »

slx26 wrote: post #67

I think the problem of this essay is that it's overly technical: only those versed well enough in SQL will really care to read the whole thing, and if they are already at that level, either they accepted that "SQL will get the job done in the end", or they learned to live along it and now even kinda embrace it, and are happy to write about how the examples are very poor and dismiss the critique based on that, when th…

We certainly do deserve better, and the author made some good suggestions.

Unfortunately, building a new database is a huge project and there appears to be no party currently willing to sponsor it.

Re: Against SQL

#342

Post by [deleted] »

papito wrote: post #156
zabzonk wrote: post #137

Earlier quoted context omitted.

> We wanted the language to be simple enough that ordinary people could ‘‘walk up and use it’’ with a minimum of training. In that case it has been an abject failure. I have been using SQL since the mid 1980s (so pretty much since the start of its widespread adoption) and I have never met "ordinary people" (by which I assume intelligent business-oriented professionals) who could (or wanted to) cope with it. I like it…

I don't think this is disputed that the original goal of SQL was a flop. The designers grossly underestimated the technical chops of a layman. However, I would argue that us tech people did benefit from that original goal of simplicity. I mean, SELECT first, last FROM employees WHERE id = 10 is not too bad at all. Kind of elegant, no? If SQL was designed "by engineers for engineers", you would be using esoteric Git c…

[deleted]

Re: Against SQL

#344

Post by maxeonyx »

exmadscientist wrote: post #83
_the_inflator wrote: post #54

I feel the pain. As someone who only uses SQL a couple of times a year, I feel that SQL shares the same fate as everything in IT: invented almost 50 years ago, not with today's world in mind, it has been blown up somewhat. Reminds me a bit of JavaScript: everything that can be done in JavaScript, will be done in JavaScript. Like after C followed C++ and here Java and others there will be new DSL and techniques on top…

I think the biggest difference between JavaScript and SQL is that there are things that SQL is actually extremely good at . For certain tasks, it really is the best language available, and not in the "least bad" sense but the "why would anyone even try to do this any other way?" sense. To get that level of applicability, of course, you have to make your problem match the form SQL needs. For applications on its home t…

Just adding that JavaScript is also the best at something - running code sandboxed - especially in a web browser. Like SQL for databases, JS has no competition for web development (because the web needs full compatibility, and adding another language doesn't have a good value proposition - just compile to JS) and thus is immensely popular.

Most languages have something they are the best at. SQL is probably THE language with the strongest value proposition - relational databases are even more important and ubiquitous than web browsers. But why doesn't SQL have any competition?

I would love to see an alternative to SQL in the style Jamie suggests. Maybe SQL would immediately not be the best anymore?

Re: Against SQL

#345

Post by Twisell »

laszlokorte wrote: post #293
goto11 wrote: post #250

Earlier quoted context omitted.

You can do that with a check constraint, although I don't know if you consider it simple. It would be cool with better support for common constraint patterns.

Could you give a concrete example for such a check constraint? I imagine each shape-table would need to have it's own check to test the existence of the same id in all other shape tables, which scales qudratically. Or if you inverse the FK to make the user-table reference the shape tables you would need multiple potential nullable columns and a check constrain that exactly one is non-null. And it would still not solv…

Are you by any chance generating GPT-3 comments as part of an experiment?

If not please take time to actually dive into modern SQL concepts there is likely a way to achieve your goal but I personally consider that it's pretty rude to ask random strangers a proof for a complex and loosely defined problem in the comments section. Stack Exchange should be a better place for instance.

Re: Against SQL

#346

Post by ris »

aliasEli wrote: post #340
ris wrote: post #192

Earlier quoted context omitted.

I think it's important to distinguish between what's highly optimizable in theory and what's easily optimizable in practise . The latter working here and now, and the latter being a (possibly perpetual) decade of compiler development away. An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly…

> An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly do that always seems to be a decade of compiler development away, with many giving up on the idea entirely. JIT has been used very successfully for a couple of languages, e.g. Java. But adding it requires a lot of effort. The same thing…

> JIT has been used very successfully for a couple of languages, e.g. Java

I'm not at all disputing that - but its promises of "beating AOT" that we used to hear have not come to fruition. Where it really matters, e.g. HPC, you don't really see any JIT. C, C++ and Fortran still rule. And even for Java, you tend to be able to achieve equal or better performance with AOT compilers.

Re: Against SQL

#347

Post by aliasEli »

ris wrote: post #346
aliasEli wrote: post #340

Earlier quoted context omitted.

> An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly do that always seems to be a decade of compiler development away, with many giving up on the idea entirely. JIT has been used very successfully for a couple of languages, e.g. Java. But adding it requires a lot of effort. The same thing…

> JIT has been used very successfully for a couple of languages, e.g. Java I'm not at all disputing that - but its promises of "beating AOT" that we used to hear have not come to fruition. Where it really matters, e.g. HPC, you don't really see any JIT. C, C++ and Fortran still rule. And even for Java, you tend to be able to achieve equal or better performance with AOT compilers.

With an AOT compiler a lot of work is done at compile time, but with JIT it is done at runtime, which makes these programs slower to start. But for programs that do run for a longer time, like servers or IDE's the performance is quite decent. But Java is a memory safe language which means that it has to do a lot of checks that unsafe languages do not have to do, which means that it will always be slower that unsafe languages. In some cases the JIT can eliminate those safety checks, but that is not always possible.

Java always had (and still has) an AOT that compiled to byte code. Adding JIT was a major improvement.

Re: Against SQL

#348

Post by goto11 »

laszlokorte wrote: post #293
goto11 wrote: post #250

Earlier quoted context omitted.

You can do that with a check constraint, although I don't know if you consider it simple. It would be cool with better support for common constraint patterns.

Could you give a concrete example for such a check constraint? I imagine each shape-table would need to have it's own check to test the existence of the same id in all other shape tables, which scales qudratically. Or if you inverse the FK to make the user-table reference the shape tables you would need multiple potential nullable columns and a check constrain that exactly one is non-null. And it would still not solv…

Check constraints are just SQL expressions, so in pesudocode it would be something like:

    (SELECT COUNT(*) shape JOIN square JOIN circle) = 1
How conveniently this can be expressed depend on the database system in question.

But if we are talking about adding features to SQL, it could have built-in support for such a constraint, just as there is built-in support for say foreign key constraints.

Re: Against SQL

#349

Post by nextaccountic »

erezsh wrote: post #36

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

What I really wanted was something compatible with SQL, but that augmented it (and compiled to plain sql). Like typescript is for javascript, but instead of adding a type system, adding constructs for better composability.

Something like.. BQL http://intelligiblebabble.com/a-better-query-language-bql-la... which went nowhere https://github.com/lelandrichardson/BQL

Re: Against SQL

#350

Post by ghusbands »

le-mark wrote: post #226
dorgo wrote: post #224

Earlier quoted context omitted.

ORMs assume that they are the only access point to the database and cache result sets based on that. Disable the cache or keep in mind that bugs can happen due to that behaviour.

Caching is orthogonal to ORMs; https://old.reddit.com/r/programming/comments/2cnw8x/what_or...

No it's not, and that link isn't relevant. Some ORMs do have caching layers and when you use those ORMs you have to know how to invalidate the appropriate caches when you update without going through them.
Post reply on HN