I don't need your query language

Post by thomasmg » Sat, Jun 17, 2023, 4:31 PM UTC

ako wrote: post #199

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

The problem with procedural is that it doesn’t optimize very well. The fastest way to get your data for a large number of random queries often depends on the data size, the available indexes, but is also influenced by changes in data size, etc. What is fast for a small dataset might be slow for a larger dataset. The right algorithm also depends on your filters and caching. It’s almost impossible to write procedural q…

Post by recursive » Sat, Jun 17, 2023, 4:34 PM UTC

DaiPlusPlus wrote: post #141

recursive wrote: post #133

Earlier quoted context omitted.

> the _only_ place where it offers a readability improvement over ext-methods is using `join` No love for let? from item in items let frob = Expenseive(item.P1) where frob > 3 selec new { frob, item }

That can be done with ValueTuples instead of Anonymous Types: `items.Select( i => ( i, frob: Expensive( i.P1 ) ) ).Where( t => t.frob > 3 );` ...and ValueTuples are superior to Anonymous Types because you can actually return them from a function or use them as parameters - whereas Anonymous Types cannot cross method-call boundaries (excepting using generics for pass-through). Anonymous Types in C# were a massive mist…

Post by erikpukinskis » Sat, Jun 17, 2023, 4:35 PM UTC

nicoburns wrote: post #43

DaiPlusPlus wrote: post #18

SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…

This is no longer true in database that have JSON support (which is most of them these days). You can aggregate the result of a subselect into a single column (the underling data doesn’t have to be stored as JSON, you can convert as part of the query)

    SELECT json_agg(trips)
    FROM (
        SELECT 
            json_agg(
                json_build_object(
                    'recorded_at', created_at, 
                    'latitude', latitude, 
                    'longitude', longitude
                )
            ) as trips
        FROM data_tracks
        GROUP by trip_log_id
    )s

Post by dan-robertson » Sat, Jun 17, 2023, 4:37 PM UTC

croes wrote: post #205

dan-robertson wrote: post #47

I don’t really find the examples convincing. Like, I get that sql could maybe be written in a slightly less horrid way but I would prefer something a lot less horrid. I think I’m much more motivated by analytics queries than the kinds of thing in this example though. I find sql is poorly suited in this case because it is verbose and written backwards, and often requires many layers of subqueries. That said, one can u…

Why do you need the outermost query?

Post by [deleted] » Sat, Jun 17, 2023, 4:44 PM UTC

karmakaze wrote: post #207

> Here is another common argument: SQL was designed with 1970s businessmen in mind, and it shows. That is a funny way of looking at it. I see that SQL is based on the work of a computer scientist vs DSLs being made by hobbyists, and it shows.