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

141–150 of 466 posts

Re: We Can Do Better Than SQL

#141

Post by Areading314 »

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…

Right, it's like criticizing python, or English, for being inconsistent, or "large". Turns out that doesn't matter -- what matters is that the language is useful because it has a wide base of users and libraries, just like SQL does.

Re: We Can Do Better Than SQL

#142

Post by Akronymus »

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.

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.

Re: We Can Do Better Than SQL

#143

Post by virgilp »

JoshuaDavid wrote: post #87
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…

Alternatively you can make a compiler from sql to your alternative, which would make it relatively easy to get the "I just want a familiar thing that works" people on board.

At that point you no longer provide a new language, but a new SQL query engine.

Re: We Can Do Better Than SQL

#144

Post by tsimionescu »

unityByFreedom wrote: post #127
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 completely agree with both the title of this post and your comment. The solution is in diagrammatic "languages"/tools like Airflow, not more query languages. Selecting columns before tables always felt weird to me. Doesn't it make more sense if you had a graphical view this way? (imagine boxes around the below items where you can drag lines to make connections between tables/inputs) USERS --user_id-- [data processi…

Given our source control tools' limitations, I will take a textual format over graphical representation any day.

Either way, queries need to be composed at runtime a lot of the time, so for many uses of SQL you can't just have the queries as blobs that you prepare ahead of time in some other tool - they must be objects you can work with programmatically.

Re: We Can Do Better Than SQL

#145

Post by Akronymus »

AmericanChopper wrote: post #136
mnsc wrote: post #107

Earlier quoted context omitted.

I think one of the challenges with sql is that beginner developers can create naive sql queries that "work" but are extremely complicated for the optimizer to "get right". So in some cases (talking from own experience) the developer can, with the use of hints, "be better" than the optimizer when the problem all along was the overall structure of the query. Edit: don't do it

The relational model can _usually_ save the day here, without a huge amount of effort. SQL certainly has its share of anti-patterns and footguns. But most of the awful SQL I’ve seen over my career hasn’t come from poor mastery of SQL, it’s come from poorly normalized schemas. If you have a properly normalized schema, then you can do a huge amount with very simple SQL. When it’s poorly normalized, you end up with all…

>footguns

Ran into one recently. Where a table was joined either to one or the other table, based on if a value was null in the first one.

This was fine, until we added a where clause to a, through multiple joins, base table for both options. This tanked the performance >1000x.[1] If we just returned the value it had basically no impact.

We tried solving it with using the result set as a base for a select where we did the filtering. This also resulted in the slow performance. In the end I solved it by wrapping the column in a function call, which solved it. And I still don't know why.

My guess is that somehow without the function call, it optimizes it into one query, which results in basically the original case, while a function forces the evaluation of the subquery first.

[1]Sub 1sec to over 15 minutes

Re: We Can Do Better Than SQL

#146

Post by Akronymus »

lmm wrote: post #116
bjo590 wrote: post #90

Earlier quoted context omitted.

> I want to be better at SQL but so many problems I hit up against and think “well that’s a 2 minute job in js/swift/php” The thing about SQL is that it's the fastest way to read&write data in a relational database. Maybe writing the code is faster in js/swift/php, but the code will run faster in SQL. If you need to do something to 100M pieces of data you can do a lot worse than SQL.

That's circular reasoning though. Why do you want your data to be in a relational database? Particularly if you're not actually using its features (I don't think I've ever seen a web application that actually got any value out of database-level transactions, for example). A different kind of datastore could offer you better performance and easier querying.

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.

Re: We Can Do Better Than SQL

#147

Post by tsimionescu »

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?

We have ORMs because our programming languages object models are not relational, they are hierarchical - from C to Haskell, everyone goes for highly non-relational data representations.

So, when we interact with a relational DB we need some kind of layer to map between the world of relations in the DB and the world of objects in our program.

Re: We Can Do Better Than SQL

#148

Post by LoSboccacc »

willtim wrote: post #135
LoSboccacc wrote: post #72

Earlier quoted context omitted.

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…

> it's not the underlying query language, SQL and it's implementations do not support nested relations. The parent is suggesting that e.g. nested relations would enable better ORM solutions.

> nested relations

parent was right that hierarchical queries are not well supported, but that's not the same as outright using nested relations; also if you're not going to store data following normal forms for convenience no wonder sql is going to have a hard time querying it.

at which point you're better off with an object storage and a searchable index to the side anyway

Re: We Can Do Better Than SQL

#150

Post by bni »

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 really like the relational model, and I think its the best way to model data. Referential integrity is an awesome thing that removes the possibility for many bugs to exist.

As for SQL it has its warts, but im pragmatic when it comes to programming languages, like for example C, JavaScript, its also "ugly" but its often the best option anyway.

Post reply on HN