While I agree that, you need to trust someone to your DNS, it shouldn’t be a specific app making that choice for you. A household or even a user with multiple devices benefits from their router caching DNS results for multiple devices, every app on every device doing this independently is foolish. If Mozilla wants to help users then they can run an informational campaign, setting a precedent for apps each using their own DNS and circumventing what users have set for themselves is the worst solution.

Comment quality is a big one. I always have to stop myself if I go to make a comment before reading the linked article. Its a bad habit from using reddit where the linked article usually has no content.

I learned most of my SQL skills on the job. I struggled a lot with SQL in the university course I took, and I didn’t grok it. But when I started to need SQL on the job, it started to “click” and I learned it properly. To be honest, I committed the sin of rolling my own framework way back when, but it meant I was somewhat forced to learn a lot of underlying stuff. When you have to generate SQL from your ORM, that’s a fantastic way to learn the nitty-gritty of SQL. You’ll even encounter the limitations of your RDBMS, as you’re almost guaranteed to run into them whilst “compiling” SQL.

I’ve also noticed that as you start to need more advanced features, many ORMs don’t support it and you’ll need to drop down to the SQL level more. This is especially true of PostgreSQL, as it has a very extended feature set. Django has some contributed support for lots of Postgres features, but other ORMs tend to cater only to the lowest common denominator, so you can’t do fancy things. Especially something like a complex UPDATE statement with a FROM query on a related table or doing an INSERT of a complex SELECT where you dynamically generate values based on another query, while returning the inserted values.

Of course, when you aren’t even aware of advanced features, you’re not likely to even want to use them. To get an awareness of what’s possible, I’d suggest reading Use the Index, Luke and just the Postgres manual, which is quite well-written and can be read like a book.

When making data migrations you’ll often want to do it directly in SQL for performance and memory usage reasons (doing it all in the procedural language is a no-go if you have a huge data set). Big data sets are the key: if you have lots and lots of data, you can’t simply slurp everything into memory and iterate over it, updating records one at a time. Bulk updates of non-static values tend to require dropping down to SQL pretty quickly unless you have a very powerful ORM.

I picked up 99% if my SQL knowledge on the job. My first job offered to pay for Microsoft certificates test taking, so I went and got the MCTS in SQL Server 2008. It was a good introduction to all the various features of SQL Server. Not sure that this qualified me as an expert, but I definitely have a decent feel for the SQL server feature set. I suspect there are similar resources for MySql, Postgresql and so on.

Since then, it’s mostly just been the odd thing here or there. If SQL interests you, I definitely recommend either getting a book, or reading up on things like window functions, (recursive) common table expressions materialized/indexed views, window functions, how aggregates work, and so on. Digging into the exclusive functionality of the database you use is also recommend There’s some interesting stuff under the hood if you take a look.

Probably the most frustrating thing about SQL, however is that most abstraction features, like functions, stored procedures, or views do not compose well from a performance perspective. One layer of them usually works well, two or more is often trouble.

On the job I learned how to use SQL to get order-of-magnitude speedups over ORM. Turns out databases are really good at querying data! For me, common-table expressions were the gateway drug and window functions were what gave me the most power.

That is one of the thing I love about SQLAlchemy, we use most of these without problem. JSONB is really nice to use, fast, efficient

The CHICKEN PostgreSQL egg, which is not an ORM but “just” a database access library (a wrapper for libpq with several additional features, much like Python’s PsycoPG) has rich support for types. I’ve written a so-called “omelette recipe” (a tutorial) about this a couple of years ago.

Most recent project I did, the SQL and the data access code was done in plain JDBC access code in Scala. The SQL uses postgres types and one or two more specialized bits. It’s worked out reasonably well; a compare and contrast with the FRM and ORMs from Scala that I did later on revealed roughly about as many lines of code, but without the support for Postgres capabilities; adding those capabilities got very fiddly and brittle, so I closed down that line of work.

Fortunately, I didn’t have to try to target multiple SQL databases. That would be Very Irritating.

I have always maintained that the “but multiple databases!” rationale for ORM is meaningless – how often do large projects change their entire data persistence strategy? How often ought they?