Comment on Is there something better than SQL?
onlinepersona@programming.dev 1 year agoIf you’re fine with simple queries, use an ORM of your tech stack. Once you have to understand querying performance and weigh usage patterns, constraints, and cache performance and size, then it’s not about SQL anymore. It’s about understanding the DBMS you use.
Simple queries don’t result in simple SQL. How many joins and subqueries do you think an SQL query would require in order fulfill “Give me the top 10 artists of the 90s whose albums were nominated for the MTV awards but didn’t win”?
In Django looks something like
nineties = (date(1,1,1990), date(31, 12, 1999) album_range=Q(albums__release_date__range=nineties) artists = Artists.objects.annotate( albums_sold=Sum("albums__sales", filter=album_range)), ).filter( album_range, nominations__date__range=nineties, nominations__won=False ).order_by("-albums_sold") top_artists = artists[:10]
What if one method wants the result of that but only wants the artists’ names, but another one wanted additional or other fields? In django you could simply use artists.only(*field_names)
and each method would provide a different set of field names. What would that look like without a capable ORM? Do you think somebody would refactor the method to add a field_names
argument? In my experience the result is a bunch of copy pasted queries that modify the query itself to add the fieldnames.
Another common thing is querying related objects. Say you simply wanted to have information about the record label of the aforementioned artists while handling the artists. A many-to-one relationship (artist has one record label, record label has many artists). You could either artist.record_label
while in your for-loop, but that would trigger an query for every artist (1+n problem). Or in django that’s artists.select_related(“record_label”)
and it will get all the record_labels in the same query.
If it’s a many-to-many relationship for example “festivals”, then .prefetch_related()
will first select the artists, then make a second query of festivals of those artists, and artist.festivals
would be available.
An ORM like django makes that simple. SQL, does not.
So, before we even get to the DB optimisation part (which indices to create, whether a view is better or now, which storage engine to use, WAL size, yadayadayada), there’s an entire interface / language that makes writing bad code very easy.
BitSound@lemmy.world 1 year ago
I’m too lazy to convert that by hand, but here’s what chatgpt converted that to for SQL, for the sake of discussion:
I like Django’s ORM just fine, but that SQL isn’t too bad (it’s also slightly different than your version though, but works fine as an example). I also like PyPika sometimes for building queries when I’m not using Django or SQLAlchemy, and here’s that version:
I think PyPika answers your concerns about
It’s just regular Python code, same as the Django ORM.