Oh, I just don't like triggers for that kind of thing, I'd even prefer a server side trace or Xe's EE's once I learn to use thamproperly (depending on version) and tere are various alerts which can be configured, depending upon what you want to track. But while I don't like "me too" answers I agree with te guys. One thing I would say though is if its a non-trivial app, design first, not code first. Other than Mom 'n' Pop's Corner Shop websites, or two screen apps - the parable of the Three Little Pig still applies.

If it's a 5 simple screens and 4k rows, it's not worth being the Relational Taliban over, lash the backend together, let them loose.

Also, I have a fairly well practiced description of how SQL Server uses memory, CPU cache, buffer memory and stolen pages. Slightly different for Dev's and network Guys, but good ones can get "Don't throw shit passthrough against a bad design" and "Yes, I know it was running at 95% memory usage, this is not a reason to reboot because the server's "Running out of memory", that's how I set it up, I'm very unhappy, here's why ... ". Good Devs hate writing inefficient code, let them know why XYZ is crap in a 10 minute chunk. Hell, things change - you will learn shit when they push back on occasion.