We Can Do Better Than SQL • Hacker News Board

Re: We Can Do Better Than SQL

#251

Post by brynjolf » Tue, Aug 11, 2020, 11:28 AM UTC

mathgladiator wrote: post #96

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.

No, I'm with you and prefer SQL for many tasks. SQL got a bad rap in many ways due to security issues, databases in general, and "web-scale". SQL as a language within other languages is a nightmare from a security standpoint, and if language integrated query was more common across languages earlier on then this wouldn't have been an issue. Databases generally depend on normalization, but normalization comes with inte…

What are examples of those "easier things"?

Re: We Can Do Better Than SQL

#252

Post by Wandfarbe » Tue, Aug 11, 2020, 11:29 AM UTC

dsego wrote: post #240

Wandfarbe wrote: post #161

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

I'm not doing C every day but i have rarely any issues with it. Do we really need to do better than C? 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 assembly etc. If you are only able to write simple C because you are not good in C/algorithms, you will not optimize your algorithms indepe…

I do see my comment in context of using SQL for your Queries while your main focus as a Developer (like for java etc.) is not writing SQLs as your main priority.

Also it does state 'we can do better than sql' and i do have a certain amount of practical experience to state my personal opinion that i do not think that their approach is actually better than sql.

They did show quite avg examples; Examples which are leading me to assume certain points like where they would like to replace sql.

Re: We Can Do Better Than SQL

#253

Post by jeltz » Tue, Aug 11, 2020, 11:29 AM UTC

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.

Isnvt that true for SQL? SQL treats everything as a relation and does not make any difference between a table, a view, a set returning function, a sub query or a CTE.

Re: We Can Do Better Than SQL

#254

Post by harryf » Tue, Aug 11, 2020, 11:30 AM UTC

mr_toad wrote: post #10

> The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases. I would dispute this. The antecedents of NoSQL were the parallel programming models of HPC. They weren’t specifically excluding SQL, and NoSQL was a term that was invented after the fact.

Agreed. The name NoSQL succeeded because it was concise and attention grabbing but the main goal wasn’t about eliminating SQL.

A big part was document oriented databases like CouchDB and MongoDB made more sense for a lot of web based use cases, where in the end you’re serving a page of content. Building a relational model often little sense for the web and makes managing the content harder; that a lot of websites can be built with a static site generator highlights that.

Re: We Can Do Better Than SQL

#255

Post by jeltz » Tue, Aug 11, 2020, 11:35 AM UTC

smabie wrote: post #140

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.

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.

Re: We Can Do Better Than SQL

#256

Post by jimnotgym » Tue, Aug 11, 2020, 11:36 AM UTC

Please leave it alone. I'm sure we can do better than English as a conversational language, knowing more about how people use it, but I don't want to learn English 2.0, because I already know English.

Re: We Can Do Better Than SQL

#257

Post by djrobstep » Tue, Aug 11, 2020, 11:36 AM UTC

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?

Just wrote a stored procedure in a text file and committed it to git. Seemed to work ok.

Re: We Can Do Better Than SQL

#258

Post by jeltz » Tue, Aug 11, 2020, 11:39 AM UTC

pkalinowski wrote: post #229

nicoburns wrote: post #218

Earlier quoted context omitted.

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.

> 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. What about common table expressions? Or custom defined functions? with X as ( select... ) It's widely used for analysis

CTEs can do that, but it is quite clunky for when you just want to reuse a partial per row computation.

Re: We Can Do Better Than SQL

#259

Post by scotty79 » Tue, Aug 11, 2020, 11:44 AM UTC

quickthrower2 wrote: post #125

gregjor wrote: post #2

Would be nice, but bazillions of lines of SQL at the core of almost every business system make this as likely as “We can do better than five fingers.” The article does nicely illustrate many of the well-known shortcomings of SQL. Chris Date and Hugh Darwen unsuccessfully tried to fix SQL with Tutorial D. Never heard of it? Exactly.

Maybe just have SQL Transpilers? I mean we accept ORMs, so we should accept that.

Linq is pretty much cool transpiler from composable sql-like dialect to SQL.

Re: We Can Do Better Than SQL

#260

Post by reportgunner » Tue, Aug 11, 2020, 11:46 AM UTC

dsego wrote: post #233

reportgunner wrote: post #212

Earlier quoted context omitted.

Sorry, but what is hard to understand about SELECT FROM WHERE =

Since it's so easy, I think you won't have a problem with any of the questions on this page: https://www.toptal.com/sql/interview-questions

Correct, but I have years of experience with SQL so I feel like I'm cheating a bit.