6 ms·
I'm a self-taught webdev too and I would strongly recommend learning SQL, not just `SELECT * ...` but really learning it! I've been digging into postgreSQL and
by _benj 6y ago
I'm a self-taught webdev too and I would strongly recommend learning SQL, not just `SELECT * ...` but really learning it!
I've been digging into postgreSQL and in quite a few applications it's possible to greatly reduce the complexity of the backend by receiving exactly the data you need from the DB. It is so much so that in cases you can even "get rid" of the backend completely (yes, no writing controllers and endpoint, etc.) by using a tool like postgREST (postgres to REST) or Hasura (postgres to graphQL)
Best of luck on your search!
- thatcodingdude 6y agoSQL made the cut on my learning list !
- bszupnick 6y agoAny specific resources to recommend?
- KiranRao0 6y agoMy favorite has been https://pgexercises.com/ https://pgexercises.com/. Instead of going through theory, you practice writing progressively more complex queries to achieve a specific result.
- _benj 6y agoThe 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...
- cpursley 6y agoUsing 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-commands-in-elixir-187c49597851 https://blog.lelonek.me/listen-and-notify-postgresql-command... Or do similar using Hasura's Event system but with webhooks. https://3factor.app https://3factor.app
- cloverich 6y agoI'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 https://theartofpostgresql.com
- modernerd 6y agoExecute Program has a great interactive course: https://www.executeprogram.com/courses/sql https://www.executeprogram.com/courses/sql
- dkubb 6y agoI 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".
- ioncube 6y agoTheory: Database Lessons by Dr. Daniel Soper (watch at x2 speed) https://www.youtube.com/playlist?list=PL1LIXLIF50uXWJ9alDSXClzNCMynac38g https://www.youtube.com/playlist?list=PL1LIXLIF50uXWJ9alDSXC... Learn by watching short videos and practicing: Mastery with SQL (paid course, $49) - https://www.masterywithsql.com/ https://www.masterywithsql.com/
- mcv 6y agoAnother 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.
- lizhang 6y agoI have gone down this rabbit hole, and I think neo4j is more suited as an analytics tool than a standalone production database: https://medium.com/@l_i/neo4j-is-a-great-platform-for-analytics-its-not-ready-for-production-yet-63220e6ec96a https://medium.com/@l_i/neo4j-is-a-great-platform-for-analyt...
- zatel 6y agoAs 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.
- mcv 6y agoExactly. 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.
- graphsandcode 6y agoNeo4j'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://kelvinlawrence.net/book/Gremlin-Graph-Guide.html https://github.com/datastax/graph-examples https://github.com/datastax/graph-examples
- Thaxll 6y agopostgREST the worst thing ever. Just use the DB to store things, thank you.
- jjice 6y agoI 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.
- Thaxll 6y agoIf 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 ...
- emteycz 6y agoAs 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
- Thaxll 6y agoIt's a bad habit because of separation of concerns.
- emteycz 6y agoYou'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.
- steve-chavez 6y ago
- landemva 6y agoGreat 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.
- postalrat 6y agoAlso learn to denormalize. Because performance matters.
- pragmatic 6y agoI 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.
- ahpearce 6y agoThat 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/patterns/interface.html http://best-practice-software-engineering.ifs.tuwien.ac.at/p...
- steve-chavez 6y agoDon'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-isolation http://postgrest.org/en/v7.0.0/schema_structure.html#schema-...
- ahpearce 6y agoYeah, 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!