Just because it's possible to buy really inexpensive SATA drives and get good performance from them, it doesn't necessarily mean you want to put them in a database server. It doesn't matter how fast your system should be if it's down because of a bad drive.
The first step toward reliable hard drive operation is for the drive to accurately report the errors it does run into. This happens via two mechanisms: error codes reported during read and write operations, and drive status reporting via the SMART protocol. SMART provides all sorts of information about your drive, such as its temperature and the results of any self-tests run.
When they find bad data, consumer SATA drives are configured to be aggressive in retrying and attempting to correct the error automatically. This makes sense given that there's typically only one copy of that data around, and it's fine to spend a while to retry rather than report the data lost. But in a RAID configuration, as often found in a database environment, you don't want that at all. It can lead to a timeout, and generally makes things more difficult for the RAID controller. Instead, you want the drive to report the error quickly, so that an alternative copy or copies can be used instead. This form of error handling change is usually the main difference in SATA drives labeled enterprise or RAID edition nowadays: those will report errors quickly, where the non-RAID versions will not. Having to purchase the enterprise version of a SATA hard drive to get reliable server error handling operation does close some of the price gap between them and SAS models. This can be adjustable in drive firmware, however; see http://en.wikipedia.org/wiki/TLER for more information about drive features in this area.
Generally, all SAS disks will favor returning errors so data can be reconstructed rather than trying to self-repair. Additional information about this topic is available, as part of a commentary from network appliance about the drive reliability studies mentioned in the following section, at http://storagemojo.com/2007/02/26/netapp-weighs-in-on-disks/.
External drives connected over USB or FireWire can be quite crippled in their abilities to report SMART and other error information, due to both the limitations of the common USB/Firewire bridge chipsets used to connect them and the associated driver software. They may not properly handle write caching for similar reasons. You should avoid putting a database on an external drive using one of those connection methods. Newer external drives using external SATA (eSATA) are much better in this regard, because they're no different from directly attaching the SATA device.