221–230 of 304 posts
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.
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…
Earlier quoted context omitted.
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)
> 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) For anyone (like me) who is not quite able to visualize this, here is an example: 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 t…
I'm super unfamiliar with this space, and would love to know whether it is a feasible/worthy goal to replace GraphQL queries with generated SQL.
Earlier quoted context omitted.
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…
I have written 4 query optimizers: HypersonicSQL, H2 database, PointBase Micro, and Apache Jackrabbit Oak. I know procedural language don't have such optimizers. But I argue that you don't always need them. I argue that the database engine query optimizer is often more a risk than a help. I have seen missing indexes far too often. SQL doesn't require that the programmer thinks how the data is accessed, so the result…
But I have little faith that people who forget indexes are capable of writing procedural queries that are always fast. These less experienced devs are the ones that benefit most from the query optimizer doing the hard work. I think the real solution is for database to automatically create indexes where needed, as some database already do. And some better visual query editor like ultorg.
Earlier quoted context omitted.
Always start with the end in mind, first what your goal is then how to achieve it. Also, i don't actually see the problem because you never write a query in a lineair way. Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. By now, code completion works as the table is known. Wouldn't help much to write it table first.
> Usually start with "select * from table limit 10", look at the columns and data available, and then start refining. An experienced person won't do that. For any moderately complex SQL query, before writing it I already have in mind the several jointures I'll need, since I usually know the tables and FK I'm working with. It's like following the edges of a graph, all in my head. But I don't know all the fields of the…
I typically keep all JOINs I've ever used on that schema in a single file, one per line.
Before writing a new query I can just copy paste some JOINs, simply skimming through table names like lego bricks.
That way it's surprisingly easy to beam from domain problem to a new query that uses 10 or 20 tables.
I've just realized that it might be all archaic now, in LLM era.
I think of SQL as one of the few good things we have in software development, so like the author I consider it best to try to do as much in SQL as possible. It's not too uncommon I run into code in other languages where I just don't understand what it does, or to write code myself that behaves in ways that surprise me. That almost never happens in SQL. Even a big hairball of a query just takes time to figure out (unl…
I tell new developers that SQL is one of those few things in our field you get to keep forever. That JavaScript framework that takes a year to understand will no longer be used in 7 years. SQL is going to be here forever and learning it is useful your whole career. Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting. Devs always pus…
With LLM's, no one is ever going to need any query language starting effing now.
And good riddance to all of them too, I've yet to see one that made any kind of sense from the ease of use perspective.
Earlier quoted context omitted.
> which costs CPU Which costs very little CPU in 2023. > deserialised on the application server This is true regardless. The low-level libraries are still parsing the stream into meaningful in-memory structures. With JSON, the low-level library only has to parse a variable length string, then JSON decode. I'm unfamiliar with any language in 2023 that doesn't have incredibly fast and efficient JSON parsers. > bandwidt…
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…
I think of SQL as one of the few good things we have in software development, so like the author I consider it best to try to do as much in SQL as possible. It's not too uncommon I run into code in other languages where I just don't understand what it does, or to write code myself that behaves in ways that surprise me. That almost never happens in SQL. Even a big hairball of a query just takes time to figure out (unl…
I tell new developers that SQL is one of those few things in our field you get to keep forever. That JavaScript framework that takes a year to understand will no longer be used in 7 years. SQL is going to be here forever and learning it is useful your whole career. Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting. Devs always pus…
Nothing seems more ephemeral than JavaScript framework du jour.
Earlier quoted context omitted.
> you get access to all scopes Read: "you create new heap-allocated closures which wreck your Linq expression's runtime performance" Or: "you create Linq queries that cannot be translated into SQL"
It was all in memory. To the extent that it's a performance tradeoff, it might be one that's worth making depending on the use.
——
On a related note, it’s interesting just how unpopular so many new C# language features are (just by looking at the numbers of Thumbs-down reactions on the GitHub Issues/PRs - stuff like top-level Main. It feels like C#’s LDT wants to be like Swift, but without Swift’s willingness to ditch ill-conceived features after a few years… but I think C# would be well-served by taking an axe to some language-features by now - like keyword-Linq and CLS-compliance (honestly, do any ISAs today still lack hardware support for unsigned ints?)