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

211–220 of 466 posts

Re: We Can Do Better Than SQL

#211

Post by PeterisP »

lmm wrote: post #158
Akronymus wrote: post #146

Earlier quoted context omitted.

I love SQL for making it possible to almost trivially enforce most business rules. Such as: You can only use one of the in another table specified values in this field.

I struggle to understand this viewpoint. In my experience business rules are harder to express in SQL than in practically any first-class programming language. "Is this value one of this list of values" - whether that list is hardcoded or dynamically obtained - is completely trivial. (Of course if you apply some double standard where editing your "source code" requires multiple approvals whereas changing your "databa…

You're arguing that business rules are easier to express in other programming language, but the point of the parent post (and SQL) is that business rules are easier to enforce in SQL.

It's trivial to write some code verifying "Is this value one of this list of values", but writing such code not ensure that this constraint will actually be met in 100% of your past and future data.

It's very difficult to guarantee that a business constraint expressed in your client app is actually enforced - there can be different versions of your app applying the constraint differently, there can be multiple apps accessing the datastore, there could be manual interventions in various ways to the datastore, the app could have code paths that may cause data insertion or alterations without running that verification in certain conditions, etc; so for all intents and purposes you can't really rely on that constraint.

Re: We Can Do Better Than SQL

#212

Post by reportgunner »

marmada wrote: post #203

I see a lot of Stockholm syndrome in this thread / maybe low expectations. Many people are saying SQL isn't that hard to learn but as someone who is new to SQL, I disagree. It takes a max of 15 minutes to understand basic JavaScript/Go/Python primitives and write a program. SQL on the other hand seems much more complex. I might as well be reading Haskell or Lisp. At least those languages are consistent. SQL does not…

Sorry, but what is hard to understand about

SELECT FROM WHERE =

Re: We Can Do Better Than SQL

#214

Post by apta »

Good post.

> Swift, Rust, Kotlin, Go, just to name a few, are great examples in the advancement of engineer ergonomics and productivity.

golang is definitely not an advancement in engineering ergonomics. It can't be grouped with the other mentioned languages.

Re: We Can Do Better Than SQL

#215

Post by viraptor »

oxfordmale wrote: post #164

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.

> However, in the end EdgeSQL will only succeed if it has a better query optimiser than Postgres, SQL Server and Oracle

EdgeQL is the query language, EdgeDB is the engine. The latter does query optimisation. In theory EdgeQL could become popular with another engine.

Re: We Can Do Better Than SQL

#216

Post by dsego »

hnarn wrote: post #155

Very few people truly understand databases, and therefore very few people truly understand SQL. I would be suspicious of any “SQL replacement” that didn’t come from someone with many, many years in the field.

This comment is such an empty statement. The one plus one equals two kind. Are you implying something? Do you know if the authors have many or few years in the field? What does it mean to truly understand databases or SQL? To point out the vacuousness, let me rephrase this statement to come up with an equally profound message of my own:

Very few people truly understand CMS-es, and therefore very few people truly understand Wordpress. I would be suspicious of any “Wordpress replacement” that didn’t come from someone with many, many years in the field.

Re: We Can Do Better Than SQL

#217

Post by tasubotadas »

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.

Gremlin - https://en.wikipedia.org/wiki/Gremlin_(query_language)

Cypher - https://en.wikipedia.org/wiki/Cypher_(query_language)

Re: We Can Do Better Than SQL

#218

Post by nicoburns »

quickthrower2 wrote: post #122
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.

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.

Re: We Can Do Better Than SQL

#220

Post by AmericanChopper »

Akronymus wrote: post #179
AmericanChopper wrote: post #156

Earlier quoted context omitted.

Imo, polymorphic associations are one of the key areas that the relational model in general struggles. You can do them in most RDBMS, but they’re always a bit janky. Even when you’re just modelling your schema, you really have to think quite hard about it, and you’ll really struggle to preserve simplicity.

In this case it was a left join sometable on sometable.someuid = isnull(someothertable.someuid, somethirdtable.someuid) I guess that is such an uncommon case that it tripped up the optimizer completely. Also: Thanks for writing "polymorphic associations". Not knowing that probably is why I struggled to find any info on it. Edit: Both tables were actually the same one, just retrieved via different joins, so different…

> Thanks for writing "polymorphic associations". Not knowing that probably is why I struggled to find any info on it.

We might have had a similar experience with this. The first time I stumbled across this problem though I was specifically trying to figure out “what is the relational way to implement polymorphism”, so I pretty much lucked into the a rather productive series of google searches.

Post reply on HN