If you're modeling relational data, it doesn't seem like you can get around using a DB that uses SQL, which to me is the worst: most programmers aren't DB experts and the SQL they output is quite often terrible.

Not to dunk on the lemmy devs, they do a good job, but they themselves know that their SQL is bad. Luckily there are community members who stepped up and are doing a great job at fixing the numerous performance issues and tuning the DB settings, but not everybody has that kind of support, nor time.

Also, the translation step from binary (program) -> text (SQL) -> binary (server), just feels quite wrong. For HTML and CSS, it's fine, but for SQL, where injection is still in the top 10 security risks, is there something better?

Yes, there are ORMs, but some languages don't have them (rust has diesel for example, which still requires you to write SQL) and it would be great to "just" have a DB with a binary protocol that makes it unnecessary to write an ORM.

Does such a thing exist? Is there something better than SQL out there?

  • BitSound@lemmy.world
    link
    fedilink
    arrow-up
    5
    ·
    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:

    SELECT 
        a.id,
        a.artist_name -- or whatever the name column is in the 'artists' table
    FROM artists a
    JOIN albums al ON a.id = al.artist_id
    JOIN nominations n ON al.id = n.album_id -- assuming nominations are for albums
    WHERE al.release_date BETWEEN '1990-01-01' AND '1999-12-31'
    AND n.award = 'MTV' -- assuming there's a column that specifies the award name
    AND n.won = FALSE
    GROUP BY a.id, a.artist_name -- or whatever the name column is in the 'artists' table
    ORDER BY COUNT(DISTINCT n.id) DESC, a.artist_name -- ordering by the number of nominations, then by artist name
    LIMIT 10;
    

    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:

    q = (
        Query
        .from_(artists)
        .join(albums).on(artists.id == albums.artist_id)
        .join(nominations).on(albums.id == nominations.album_id)
        .select(artists.id, artists.artist_name)  # assuming the column is named artist_name
        .where(albums.release_date.between('1990-01-01', '1999-12-31'))
        .where(nominations.award == 'MTV')
        .where(nominations.won == False)
        .groupby(artists.id, artists.artist_name)
        .orderby(fn.Count(nominations.id).desc(), artists.artist_name)
        .limit(10)
    )
    

    I think PyPika answers your concerns about

    What if one method wants the result of that but only wants the artists’ names, but another one wanted additional or other fields?

    It's just regular Python code, same as the Django ORM.