SQL made the cut on my learning list !

Another option is to learn Graph Databases. I notice there's still a big shortage in people with Graph DB experience, and they're not that hard to learn. Try Neo4J, for example.

Neo4j's tutorials are great. But I also agree that they are better for graph analysis.

I've been using Gremlin for crud ops in my apps. I recommend these two resources on Gremlin:

https://kelvinlawrence.net/book/Gremlin-Graph-Guide.html

https://github.com/datastax/graph-examples

As a self taught developer I also found Neo4j's query language (Cypher) to be way easier to read than sql. Especially for building complex relationships between data which I find to be kinda a pain in sql. Also the web interface for viewing your database is really easy to use. Although I should say I've switched to using more sql databases over the past year or two because there are way more hosting solutions that support them out of the box.

Exactly. SQL is great for data that's mostly tabular, but despite their name, relational databases are not great at dealing with relations. We had some queries that required 10 joins. The same query in Cypher is trivial.

But yes, hosting solutions are terrible at supporting graph databases. Some do have a thin Graph DB layer (often using Gremlin as QL) over a Mongo-like database, but it's not the same thing.

That is not always a great idea. There is a reason APIs exist, and backend service layers exist on top of databases. It is a larger abstraction of the interface design pattern.

It only makes sense if you're absolutely sure you'll never need to extend or change the interaction between front-end and back-end.

Think just about schema migrations on the database. If you change your schema, you have to change your front-end. Maybe that's okay for the time, but that can get out of hand pretty quickly.

On the other hand, with a service layer, you could completely decouple that dependency on the front-end, by providing the front-end an interface (the service layer / API). The migrations on the database layer don't affect the front-end whatsoever, because the front-end communicates with the interface. You can change the underlying implementation without changing the front-end's interaction with the interface.

http://best-practice-software-engineering.ifs.tuwien.ac.at/p...

Don't forget that the database is not only tables. Abstraction can be done at the SQL level with views.

With views you can maintain backwards compatibility despite migrations happening. No need to change your front-end.

Check this section of the PostgREST docs for more details:

http://postgrest.org/en/v7.0.0/schema_structure.html#schema-...

Yeah, views can definitely fit certain use cases. I've just never encountered cases where I eventually don't need to /do something else/ in between those two layers. Granted I'm doing a lot of systems integration on a lot of complex legacy infrastructure, so that might just be me!

Any specific resources to recommend?

My favorite has been https://pgexercises.com/. Instead of going through theory, you practice writing progressively more complex queries to achieve a specific result.

I've only used it as a reference, but the art of postgresql is pretty solid. In general any webdev who isn't skilled at SQL is missing out on an easy way to level up. SQL is crazy powerful, versatile, and scalable, and takes a small amount of time to gain proficiency, and stays with you. I methodically read one 350 page book in 2012 and still feel I understand SQL better than most I come across. That's kind of silly. I recommend learning enough to understand the gist of aggregates and window functions. Once you understand what they can do, you can easily reference the syntax when needed.

[1]: https://theartofpostgresql.com

The postgresql documentation is actually a pretty good start (and finish!).

I like learning by doing something so I took an old side project and I'm making it on PostgreSQL with PostgREST in front of it. It is crazy all the things that the DB can do! Triggers after an actions happens, virtual columns, JWT Tokens, Unit Testing...

Using postgrest and combining postgres triggers with Elixir listeners, you can then do callback like actions on the data: https://blog.lelonek.me/listen-and-notify-postgresql-command...

Or do similar using Hasura's Event system but with webhooks.

https://3factor.app

Theory: Database Lessons by Dr. Daniel Soper (watch at x2 speed) https://www.youtube.com/playlist?list=PL1LIXLIF50uXWJ9alDSXC...

Learn by watching short videos and practicing: Mastery with SQL (paid course, $49) - https://www.masterywithsql.com/

I would recommend SQL and Relational Theory by CJ Date.

It completely changed how I use SQL. Before reading it, I had about a decade of experience with SQL. I didn't really understand the theory underneath. I also didn't understand how to write SQL in a way that adheres to the theory.

You can think of this book as being the closest we have to "SQL: The Good Parts".

Execute Program has a great interactive course:

https://www.executeprogram.com/courses/sql

Great suggestion on learning SQL. Also, learn how to normalize, at least to 3rd normal form. Clean data, enforced in the DB with constraints, makes debugging easier.

Consider getting a used Jeep in stock form, and get the shop manual. Methodically go through all of the maintenance items. Then start some easy mods, like a block heater. Good life skills.

Also learn to denormalize. Because performance matters.

I thought knowledge of sql and RDBMS's was table stakes for a Web developer job? Same with html, CSS and js.

However the more I work remotely the more I find that not to be the case.

postgREST the worst thing ever. Just use the DB to store things, thank you.

I don't see what's so bad. Seems like it would be a convenient way to skip some boiler plate back end code used for CRUD. Probably not optimal for a complex application, but it looks very neat for something quick and small.

If you're learning backend services, don't start by things like postgREST, it's just bad habbit, would be better to start by the basis with API servers / DB ect ...

As a seasoned TypeScript backend/fullstack developer I don't understand

- why is it such a bad tool, and if it is because of the tool and not the concept, it seems possible it will be fixed in the future

- why is it a bad habit; I consider the boilerplate CRUD code I write to be a bad habit that I should've automated years ago, and that's exactly what PostgREST does

- why can't you learn the basics of API services and databases with PostgREST

It's a bad habit because of separation of concerns.

You're not forced to write your app code in the DB as SQL procedures, you can also write TS or whatever else and use it next to PostgREST.

Check this thread[1] for a previous discussion about "separation of concerns" and PostgREST.

tl;dr: business logic can be done with views/sps on an isolated schema. More layers makes the overall OLTP system less performant and harder to scale.

[1]: https://news.ycombinator.com/item?id=21438307