Plus databases like Postgres have key/value and JSON data types. Once you are sure that is what you need it’s still there.
Rob Pikes 5th rule of programming: Data dominates.
Plus databases like Postgres have key/value and JSON data types. Once you are sure that is what you need it’s still there.
Rob Pikes 5th rule of programming: Data dominates.
Learn how the JOIN syntax works[0], and how to use OUTER JOINs.
Learn about WINDOW[1] functions and what kind of problems they can solve. In particular, many reporting needs can probably be solved with WINDOW functions instead of tracking state as you loop through a result set in application code.
Learn about Common Table Expressions[2]. While these usually aren't necessary, they can make your queries a LOT more readable.
The thing about learning this type of stuff is that it doesn't matter what database you learn on, you can use it on virtually any SQL database (possibly requiring minor syntax changes).
[0] https://www.postgresql.org/docs/12/tutorial-join.html and https://www.postgresql.org/docs/12/queries-table-expressions...
Books: 1) SQL Antipatterns https://pragprog.com/book/bksqla/sql-antipatterns
2) Effective SQL https://learning.oreilly.com/library/view/effective-sql-61/9...
A couple years ago I got dinged on a take-home project that involved building a db schema, but didn't get any specific feedback on my work, and it's sort of haunted me to this day (especially since SQL is one of my primary languages)
https://www.amazon.com/Joe-Celkos-SQL-Smarties-Programming/d...
Although it is 10 years old, not much has changed in the universe of SQL basics. If I were to capture the essence of good schema design it is mostly about keeping data normalized until you have a really good reason not to. Denormalization is almost always an optimization choice.
And before you optimize you should have basic things covered, like indexes, etc. I have fixed more than one "slow" query by simply adding indicies to everything people are joining on. So, check out a tool like pgAdmin that has a cool query planner optimization feature. What is happening under the hood doesn't matter a /lot/ when learning SQL, but it is really insightful to see how indicies of various types impact performance. I believe this book basically covers it all from a theoretical perspective. Optimization and indices aren't super well covered in SQL for smarties, which make sense, it isn't about optimization but is a little higher level.
There are /tons/ of data sets out there now a days. CSV files, etc. Find some interesting data and start challenging yourself with interesting ways to design that data into a database. I actually design most of my SQL databases using an ORM these days, but, my bedrock knowledge of SQL makes it very efficient and I can avoid committing "SQL sins" (denormalization) prematurely. You will be surprised at how much you can learn on simple data sets :)
The way the course is broken up now, you may need some of the other sections [2] like Intro to Relational Databases or Relational Algebra as prerequisites, since I do not remember if it used SQL syntax.
[1] https://lagunita.stanford.edu/courses/DB/RD/SelfPaced/about
[2] https://lagunita.stanford.edu/courses/DB/2014/SelfPaced/abou...
learning SQL seems much more straightforward than learning NoSQL. personally I'd like to find a good resource that will help me use a non-relational database without creating a mess
My plan for the day when someone requires me to use NoSQL is to say that postgres supports JSON/JSONB perfectly so I can use that as a NoSQL database and then use the relational part to keep me out of the mess...