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

71–80 of 466 posts

Re: We Can Do Better Than SQL

#71

Post by mr_toad »

chx wrote: post #40
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.

> The antecedents of NoSQL were the parallel programming models of HPC. Can you elaborate on what you are thinking of? As a refresh, here's when and how the (current usage at least) of NoSQL was introduced: https://subscription.packtpub.com/book/big_data_and_business... in 2009. > As Oskarsson had described, the meeting was about open source, distributed, non-relational databases, for anyone who had "… run into limit…

I’m referring to Google’s 2004 MapReduce paper.

The functional style that MapReduce derives from had been used in parallel computing models, e.g. the scatter/compute/gather model of MPI, and in turn this was adopted by Hadoop, CouchDB, MongoDB and others.

Re: We Can Do Better Than SQL

#72

Post by LoSboccacc »

jayd16 wrote: post #62

I'm not convinced by a lot of the comments here focusing on SQL as an irreplaceable juggernaut. Currently I think Postgres is just fantastic but recent DBs have shown that even SQL can bleed. There's some neat stuff here and I hope the project well. I would love to see object/hierarchical result set support grow. SQL ORMs feel so kludgy.

SQL orm feel kludgey because they are, entities on rdbms are normalized in their fractional parts and interconnected by a multitude of relations so that you have multiple entry point to obtain different views of the same data and multiple ways to organise and prune results to find interconnection across multiple entities

once you reduce all that to object traversal all your options are lost, your only entry point is the entity and the only connections are direct paths

it's not the underlying query language, it's the flattening to object

Re: We Can Do Better Than SQL

#73

Post by tialaramex »

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.

> Never heard of it? Exactly.

"Accrington Stanley"

https://www.youtube.com/watch?v=zPFrTBppRfw

Re: We Can Do Better Than SQL

#75

Post by AmericanChopper »

GeneralMayhem wrote: post #68
ckocagil wrote: post #32

I'm not impressed for two reasons: 1. Anyone striving to build a better SQL should make a comprehensive list of common (but difficult!) database tasks for OLTP and OLAP workloads. This will expose the weakness of their language. SQL has had 50 years and myriads of improvements to cover all these common cases. This is not a fair fight, so come prepared. 2. It's not enough to be just "better than SQL" to replace it. SQ…

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 deal with this problem as an Oracle DBA, and it’s a complete nightmare. It starts with a statistics refresh ruining a couple of execution plans, so you start specifying them manually with the plan manager. Then it gets worse over time, because stats refreshes become a big risk and you don’t want to do them anymore. Eventually you get to the point where you pretty much only run verified plans. Then your verified plans slowly degrade overtime, because the underlying cardinality of every table is constantly changing. You’ve replaced the query optimiser with yourself, which is not only tedious work, but it’s simply not possible to do the job as well as any mainstream DB engine could.

Re: We Can Do Better Than SQL

#77

Post by hans_castorp »

> There are many more cases like these, and there is no consistency in a single SQL implementation, let alone across all implementations

So you decided to create yet another incompatible "SQL"?

https://xkcd.com/927/

And quoting MySQL's broken handling of a division by zero as a reference. Seriously?

Re: We Can Do Better Than SQL

#79

Post by dodobirdlord »

riku_iki wrote: post #50
gen220 wrote: post #17

Earlier quoted context omitted.

> The NoSQL movement was born, in part, out of the frustration with the perceived stagnation and inadequacy of SQL databases I'm a little bit young, but isn't this a bit of a revisionist take, by the author? I thought that Amazon, Google, FB et al moved away from relational databases because the sharding logic they needed to build on top of these databases was approaching the complexity of a RDBMS. They didn't need s…

> I thought that Amazon, Google, FB et al moved away from relational databases Surprisingly, Spanner has tables with columns and you can run SQL on top of it.

Though notably the SQL interface was not present initially and was added later.
Post reply on HN