3 ms·

Sure thing. I think learning SQL is never wasted time. Try looking into SQL functions & TRIGGERs, LATERAL JOINs, ROLLUP & CUBE. If you have even more time, ch

by rntksi 7y ago

Sure thing. I think learning SQL is never wasted time. Try looking into SQL functions & TRIGGERs, LATERAL JOINs, ROLLUP & CUBE. If you have even more time, check out the different things an SQL server can do when you DROP a row that contains references, how you define CONSTRAINTs, and some particular features that only some subset of SQL dialects have, such as LISTEN/NOTIFY for PostgreSQL.

UweSchmidt 7y ago
And, for anyone looking to pick up the basics: These ancient websites got me up to speed ages ago: www.sqlcourse.com www.sqlcourse2.com
pathseeker 7y ago
>Try looking into SQL functions & TRIGGERs, LATERAL JOINs, ROLLUP & CUBE. If you're a developer, I would look into CONSTRAINTS way before getting to anything like this. Learning how to model your constraints correctly in the database (preventing duplicates, etc) is one of the most important bits of schema design because it will save you tons of code and likely a bunch of race conditions.
freeqaz 7y ago
Knowledge is power and knowing more deeply about what your database is capable of is very helpful. It's worth knowing every tool in your tool chest! That said, be careful with going too overboard with one specific tool (SQL). You may find yourself using a hammer for everything, when another tool may be more appropriate. More specifically, it's easy to abuse advanced SQL constructs to create a mess for yourself. Too much business logic in the database is something I've seen become a nightmare for other programmers looking at software later. :) This post[0] goes a bit into more detail about explaining where you should keep your "business logic" when choosing to put it in code or into SQL. 0: https://softwareengineering.stackexchange.com/questions/194446/how-much-business-logic-should-the-database-implement https://softwareengineering.stackexchange.com/questions/1944...

by rntksi 7y ago

UweSchmidt 7y ago

And, for anyone looking to pick up the basics: These ancient websites got me up to speed ages ago: www.sqlcourse.com www.sqlcourse2.com

pathseeker 7y ago

>Try looking into SQL functions & TRIGGERs, LATERAL JOINs, ROLLUP & CUBE. If you're a developer, I would look into CONSTRAINTS way before getting to anything like this. Learning how to model your constraints correctly in the database (preventing duplicates, etc) is one of the most important bits of schema design because it will save you tons of code and likely a bunch of race conditions.

freeqaz 7y ago

Knowledge is power and knowing more deeply about what your database is capable of is very helpful. It's worth knowing every tool in your tool chest! That said, be careful with going too overboard with one specific tool (SQL). You may find yourself using a hammer for everything, when another tool may be more appropriate. More specifically, it's easy to abuse advanced SQL constructs to create a mess for yourself. Too much business logic in the database is something I've seen become a nightmare for other programmers looking at software later. :) This post[0] goes a bit into more detail about explaining where you should keep your "business logic" when choosing to put it in code or into SQL. 0: https://softwareengineering.stackexchange.com/questions/194446/how-much-business-logic-should-the-database-implement https://softwareengineering.stackexchange.com/questions/1944...