How big are they anyway? For the log file, you may need to regularly backup
your database log to contain its size. If it's already grown larger than it
should, you may have to shrink it first, and then implement a regular log
backup schedule. Also, you need to watch your transaction sizes. If you run a
very large single transaction, you can blow up your log even with regular log
backups.

The data file (.mdf) shouldn't really grow >too< large. I'd check the table
sizes and see which tables are taking up the most significant portion of the
overall database size, and go from there. There are cases where if a table
doesn't have a clustered index, it may be using more space than it should.
That may or may not apply to your case.

Linchi

absolutely.  The ldf is not really a separate entity but an integral
part of the database.  Transactions are first made in memory and written
to the logfile at the same time.  Subsequently committed transactions
are rolled into the mdf/ndf by a background checkpoint process.  This
facilitates data recovery in the event of failure -- so the database at
any given time consistes of the committed trasactions in the log file
and the mdf/ndf files. Without this write ahead logging, you very
quickly end up with a trashed database and loss of ACID properties. Do
*not* delete the ldf's -- might want to check out BOL (Books on Line)
for more information.