I'm not sure if this is a good question given that the title
of your book mentions SQL explicitly...but anyway...
Does your book also elaborate solutions concerning application
design in general, but in particular those decisions regarding
for example whether to put business logic in the database
(e.g. with PL/SQL) or not, when to do so, when not...etc.
My book tries to identify common blunders. I didn't write about the merits of using stored procedures in my book, because I consider neither using stored procedures nor using application code to be a blunder. As developers, we should use the language and environment where we are the most productive. So it depends on the tools you have available, and the skills and experience of the individuals in your team.
There are those who say every database interaction should be through a stored procedure interface. There are others who insist the database should be a dumb persistence store, and all constraints and domain logic should be implemented in application code. I think both of these positions are too inflexible, too unequivocal.
I'm a proponent of using referential integrity constraints (foreign keys) in the database, and of using these constraints to implement cascading delete and cascading update. But on the other hand, I seldom write triggers or stored procedures unless there's a significant advantage for the sake of logic or performance.