It seems that I see more and more posts about people trying to shrink their transaction logs. It's getting to be close to the time when I need a cut-and-paste snippet stored in a file I can pull out for my standard "it is recommended that you do not shrink the data or log files" post response.

The vast majority of the people that want to shrink their logs do so because they're running out of disk space and they realize that their log file is 25x the size of their data file. I'll see a 500MB data file and a 12GB log file all too often because they've set up full backups (good move) and not log backups (bad move). I won't go through all the scenarios or the advice that should be given, mostly because I think I've typed it all a few times in the last few weeks.

The more interesting question is how do we try and prevent this from happening?

The default recovery model is full, which means log backups are needed. Should SQL set up backups by default? I am starting to lean towards this being a default as a part of creating a database. Something should ask for, or perhaps set up, a backup scheme that makes sense. The backup folder should be set at installation, and a warning popped up if it's on the same drive letter as the data files. Then a standard nightly full, every 4 hour log backup should be set up. Those are some guesses I'd made, and they could be changed to something that might be better suited to most databases.

And we'd need an option to disable this default for those people that have automated processes in place to handle backups.

That, of course, isn't so easy to set up for Microsoft. You need Agent running, you are now making it hard to create a database, etc. Maybe a pop-up at the end of a database creation? Maybe a standard "to do" or reminder that comes up in SSMS whenever a database has 2 full backups wtih no log backups?

There are any number of ways to handle this, but I think that the educational aspect of the need is the biggest problem. It seems that without some heavy education, or some IN-YOUR-FACE dialog, maybe in Visual Studio, the issue isn't reaching enough Accidental DBAs and developers.