I don't need your query language

Post by mattmanser » Sat, Jun 17, 2023, 1:47 PM UTC

tomnipotent wrote: post #111

mattmanser wrote: post #104

Earlier quoted context omitted.

No, you can't use 'negigibly' worse as a defence. It's either better, or not. Your comment does not make it better, it's still worse. So it won't improve performance, but degrade it, even if it's negilible. So there's no reason to do it. Plus you've made a crazy SQL select instead of a normal one, which is harder to maintain. So it's worse performance and worse maintenance. i.e. don't do this, it's dumb, especially f…

> you can't use 'negigibly' worse as a defence Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory). > made a crazy SQL select instead of a normal one, which is harder to maintain. Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's a…

Post by recursive » Sat, Jun 17, 2023, 1:48 PM UTC

DaiPlusPlus wrote: post #20

tester756 wrote: post #9

Earlier quoted context omitted.

C#'s LINQ (query syntax, not methods) got it right var result = from s in stringList where s.Contains("Tutorials") select s;

or just `var result = stringList.Where( s => s.Contains("Tutorials") )` I can't stand the non-extension-method Linq syntax: the _only_ place where it offers a readability improvement over ext-methods is using `join` - but I hardly ever do that in Linq anyway. Also, in both my code and yours, `result` will be a lazy-evaluated `IEnumerable ` which may be undesirable - which means it's probably a good idea to use `.ToLi…

    from item in items 
    let frob = Expenseive(item.P1) 
    where frob > 3 
    selec new { frob, item }

Post by daxvena » Sat, Jun 17, 2023, 1:51 PM UTC

iLoveOncall wrote: post #38

LunicLynx wrote: post #4

The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.

This is a strength, not a weakness. It forces you to only select what you actually need, and state where it comes from afterwards, to only limit your query to exactly what you need. This is paramount for performance. If autocompletion is your issue, just get a better client, it's perfectly possible to autocomplete field names even before specifying database or table name.

Post by mattmanser » Sat, Jun 17, 2023, 1:52 PM UTC

411111111111111 wrote: post #122

tomnipotent wrote: post #111

Earlier quoted context omitted.

> you can't use 'negigibly' worse as a defence Absolutely you can when the increase in something (bandwidth) in a system with surplus supply with the trade-off of optimizing a more constrained supply (CPU or memory). > made a crazy SQL select instead of a normal one, which is harder to maintain. Purely subjective. Myself nor the people I've hired would have a problem maintaining a more complex SQL query using CTE's a…

The funnest part of outputting JSON from the query is that your API now basically becomes a RPC, as you don't have to do any marshalling/deserialization before returning the response with Content-Type application/json Response times are really fast like that, as you probably already know. Always fun to see Also no worry about n+1 queries, as they're fundamentally impossible to do like that

Post by IanCal » Sat, Jun 17, 2023, 1:54 PM UTC

galaxyLogic wrote: post #136

The problem with SQL is that it is not a (very) composable language. The documentation for EdgeDb goes into some detail about that and shows an alternative better language for data-queries. https://www.edgedb.com/showcase/edgeql To understand why SQL is bad, you must first be shown something better, and EdgeDb seems to be such better more composable language.