Against SQL • Hacker News Board

Re: Against SQL

#291

Post by AtNightWeCode » Sat, Jul 10, 2021, 5:34 PM UTC

Not that bad workarounds. The N + 1 problem is usually not a big issue with ORM:s but one should the check the generated code I think. Seen far worse written code. (Well, if you don't do SELECT *...)

I have other issues with SQL:

The linear way resources are needed with the amount of data but no built in way to handle it.

That integer ids are way overused and basically locking every database to a specific environment.

The index tweaking.

The workarounds for write speed.

The fact that you can do anything in SQL and people know it.

Re: Against SQL

#292

Post by mlinksva » Sat, Jul 10, 2021, 5:37 PM UTC

Inspiring article (I love SQL, but it's also frustrating). My only wish would be to see the criticisms used as a checklist to evaluate SQL improvements or new query languages.

EdgeQL, indirectly linked at the end of the article, looks at a glance like it might score well. EdgeDB's blog post [1] criticizing SQL and introducing EdgeQL seems to cover the same concepts (inexpressive, incompressible, non-porous) with slightly differing language in some cases (e.g.. system cohesion for porousness).

Noticed after posting this comment that there's a post today about EdgeQL. [2]

[1] https://www.edgedb.com/blog/we-can-do-better-than-sql [2] https://news.ycombinator.com/item?id=27793398

Re: Against SQL

#293

Post by laszlokorte » Sat, Jul 10, 2021, 5:38 PM UTC

goto11 wrote: post #250

laszlokorte wrote: post #244

Earlier quoted context omitted.

But can you can not (in a simple way) prevent that both a circle and a triangle point to the same user and you can not enforce a NOT NULL for a user to must have a favourite shape.

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 solve the query side of things.

Re: Against SQL

#294

Post by goto11 » Sat, Jul 10, 2021, 5:41 PM UTC

deergomoo wrote: post #263

goto11 wrote: post #111

Earlier quoted context omitted.

SQL is often conflated with the relational model (hence the term NoSQL for non-relational databases), but the article is careful to explain that the relational model is great, but SQL is a clunky syntax/standard. Going to graph databases is certainly throwing the baby out with the bathwater. The relational model was invented to address shortcomings in the hierarchical and graph database models.

Aren’t you just doing the same thing in reverse here? You can use GraphQL with a relational database.

Fair enough! But GraphQL returns data in a hierarchical format, so the property of relational closure is lost.

Re: Against SQL

#295

Post by pc86 » Sat, Jul 10, 2021, 5:44 PM UTC

balfirevic wrote: post #273

bob1029 wrote: post #270

I feel like most frustrations with SQL boil down to fighting against a shitty schema. When you are sitting in a properly normalized database, it is a lot easier to write joins and views such that you can compose higher order queries on top. If you are doing any sort of self-joins or other recursive/case madness, the SQL itself is typically not the problem. Whoever sat down with the business experts on day 1 in that c…

> I feel like most frustrations with SQL boil down to fighting against a shitty schema. Which one of the frustrations from the article boils down to fighting against shitty schema?

The vast majority of recursion in SQL is probably the result of a bad schema.

Re: Against SQL

#296

Post by AtNightWeCode » Sat, Jul 10, 2021, 5:46 PM UTC

progre wrote: post #14

I do love SQL and at least where I live (MS SQL Server) it can be made to run amazingly fast if you take some care with your queries and indexes. It's not portable though: as far as I know not a single one of the big sql vendors follows the standards 100% and more importantly, spending some time with one vendor will give you some habits that are sure to not work as well with another (cursor constructs are generally a…

Use a tool to generate the SQL schema. Then you can generate it to different DB types. Stored procedures is what breaks things in my experience.

Re: Against SQL

#297

Post by jandrewrogers » Sat, Jul 10, 2021, 5:53 PM UTC

mcv wrote: post #277

goto11 wrote: post #111

Earlier quoted context omitted.

SQL is often conflated with the relational model (hence the term NoSQL for non-relational databases), but the article is careful to explain that the relational model is great, but SQL is a clunky syntax/standard. Going to graph databases is certainly throwing the baby out with the bathwater. The relational model was invented to address shortcomings in the hierarchical and graph database models.

Do graph databases predate relational databases? Do you have a source for that? I thought graph databases were a fairly new thing. I only recently started working with a graph database (a bit over two years now), and it struck me just how terrible relational databases are at relationships, compared to graph databases. I know nothing about the history of databases, but my impression is that relational DBs are basicall…

Graph databases have been around nearly as long as databases generally, at least since the 1970s. The sole feature that makes a database a "graph database" is support for a minimal amount of recursion in queries, which was a feature before SQL even existed. There are good technical reasons graph databases have never been commercially successful.

Most databases support some form of recursion and have for decades. The reason they don't market themselves as a "graph database" is that the performance and scalability of graph data models in conventional database architectures is typically very poor, so representing your entire data model that way is not encouraged. The way indexing is implemented in many traditional database engine designs, e.g. B-trees, is pathological for some common graph-like traversals. Even databases that market themselves as "graph databases" have conventional internals and perform only marginally better for graph data models than databases that are positioned differently.

The idea of graph databases are great. Unfortunately, the existing implementations all suffer from very poor scalability due to fundamental limitations of the data structures and algorithms used internally. The core theoretical challenges are well-understood but few people are credibly working on addressing those.

Re: Against SQL

#298

Post by culebron21 » Sat, Jul 10, 2021, 5:57 PM UTC

dvdkon wrote: post #194

erezsh wrote: post #183

Earlier quoted context omitted.

I don't have a lot of experience writing Lisp-y code, so perhaps I'm speaking from ignorance, but I think there is a reason that syntax never gained huge traction. Imho a syntax that's concise and expressive is important for effective coding. Having operators for the most common operations is just a small complication that yields a big reward. Having said that, the amount of keywords and operators that you see in Pre…

Thanks for the reply. I'm happy that others are also tackling the problem of a better query language. My approach isn't actually a full-on Lisp with parentheses and all, rather it's based on a single compound data structure (like Lisp's cons cell, but more like Lua tables). I call it an "arg-tuple", and it's basically a function's arguments in Python, but as a data type (which allows nesting). Add in a simple functio…

I tried developing a syntax like this: a table is set as context, then you do some transformations in pipeline fashion. That seems promising, but trying to rewrite some of my reallife examples, I found out that pipelines are much shorter than I expected. The reason was that you take a couple of tables, then make 3-4 of them (by filtering and grouping), then mix them together. And this does not fit well into pipeline structure, even with heavy nesting. In the end, the most gain on real examples (Python & Pandas) was where I made a function-like operation, which can be as well written in Python.

I can share some sketches if you wish (maybe it can give some ideas).

But generally, I think the code could be rather structured around calculation graph, than a linear sequence of operations.

Re: Against SQL

#299

Post by bob1029 » Sat, Jul 10, 2021, 5:59 PM UTC

balfirevic wrote: post #273

bob1029 wrote: post #270

I feel like most frustrations with SQL boil down to fighting against a shitty schema. When you are sitting in a properly normalized database, it is a lot easier to write joins and views such that you can compose higher order queries on top. If you are doing any sort of self-joins or other recursive/case madness, the SQL itself is typically not the problem. Whoever sat down with the business experts on day 1 in that c…

> I feel like most frustrations with SQL boil down to fighting against a shitty schema. Which one of the frustrations from the article boils down to fighting against shitty schema?

None of them in particular. The author of this article seems mostly concerned with constructing pedantic strawmen and handily defeating them with clever demonstrations. Claiming SQL is not expressive is a fault on the part of the developer of the schema. The notion of a broader ER model and why a good one matters seems to have completely eluded the author, aside from a brief mention of 6NF (which is definitely not the right place to start the conversation on normalization).

It is really easy to take a negative stance on a technology and poke holes in it without having some grounding in reality. If you are dealing with a problem domain that has hundreds of types/facts/relations, and the need to author logic spanning all of these things all at once, you are going to have a hell of a time managing this with any other technology. Looking at SQL through the lens of toy problems is a massive mistake. You have to look at it through the lens of the worst problems imaginable to begin seeing the light.

I used to think SQL was some ancient trash until I saw the glory of a 40 table join in a factory automation setting. If you need dynamic, hard answers right now, SQL is the only option that makes sense at this kind of scale.

I felt it would contribute more meaningfully to the overall discussion on HN if I were to sidestep a direct critique and present a view of the problem from a different perspective.

Re: Against SQL

#300

Post by bob1029 » Sat, Jul 10, 2021, 6:00 PM UTC

pc86 wrote: post #295

balfirevic wrote: post #273

Earlier quoted context omitted.

> I feel like most frustrations with SQL boil down to fighting against a shitty schema. Which one of the frustrations from the article boils down to fighting against shitty schema?

The vast majority of recursion in SQL is probably the result of a bad schema.

I agree with this. If you are doing recursion in SQL, its probably because you have a bad schema. If the schema is clean, then you should probably be doing the recursion in your application logic. There are still cases where it makes sense but its super rare in my experience.