I believe Nina meant to say "run as script" as opposed to "run as SQL" if I'm remembering the host SQL window.
You can truncate your EventLog and SiteLog tables which will empty them out completely. But going forward you'd want to set this to happen via the scheduler, so the size of these tables is kept under control by removing entries over x number of days - whatever fits your needs.
As far as setting the database to grow by a set amount rather than by percentage - that may be good advice, possibly not in every case, but in many cases. However, the size of the database isn't affected by this as much as is performance. If the database server has to increase the size of the database often, then it is using resources (CPU cycles and disk I/O) to do that rather than serving data. If it grows by larger chunks, then it has to grow less often. That isn't necessarily a choice between percent value or MB value. If you have a 2Gb database and it grows by 10% - that's a couple hundred Mb. It probably won't have to grow again for a while. Not a bad choice. If you have a 20 Mb database, and it grows by 10%, the server will do a lot of work just growing the database until it reaches a mature size of whatever - 500 Mb, say. how many times did it have to increase the size of the db to get from 20 Mb to 500, at 10% ... way too many! If you set it to increase by 100Mb whenever it needs to grow ... then it only had to grow 5 times to get there.
But again, that issue does not cause a database to bloat; it tends rather to degrade performance.
Performance-wise, it is actually better to let the database stay larger (within reason) rather than trying to keep it as small as possible. That way the server doesn't have to spend resources shrinking and growing the database. Diskspace is cheap; performance always matters.
If your database continues to grow large, then perhaps it is not being backed up properly, in which case the transaction log cannot be truncated (not the same as shrinking a database). That is not a DNN issue, but rather an SQL issue.
If you know that your db is being backed up, that the transaction log is therefore getting truncated, that you have scheduled maintenance on your event log and site log, then you should not have other concerns about the size of your database. Let it find its natural size and let it keep its disk space. Wrestling disk space away from it in an attempt to always keep it pruned and small is just a performance drain.
Switching to simple mode likewise depends on regular database backups to keep the transaction log small (else it will eventually fill the disk!). However, you lose the ability to back your site up to a designated point in time. Not a choice I make for sites that are at all critical.