I think applying design patterns blindly without understanding what problems they’re supposed to solve is often more harmful than not using them. It can lead to difficult to manage code bases because the program is over engineered for problems that don’t exist.
My general rule of thumb is to write code that can be easily adapted to unexpected changes in requirements. Avoid writing code that paints yourself into a corner. Simple solutions are often easier to work with than complex solutions. If what you’re doing adds a lot of complexity, take a step back and seek other options. Maybe you’re overlooking an obviously simple solution to the problem?
I think inheritance almost always has this “painting yourself into the corner” tendency. Once the design is set, it’s often difficult to break free from it. Composition along with interfaces is generally the better choice. Often not even interfaces are needed.
This comes with experience. You learn what works, and what doesn’t. Often you do it the hard way.
Databases are tricky. I have no good advice for that.