TL;DR: Use a combination of mirroring and log-shipping, depending on your needs; high-availability should not be the responsibility of the DBA, alone.

From a purely technical standpoint, I find that I always use a combination of Database Mirroring and Log Shipping, depending on the situation I am covering. I understand when a tight budget is a factor here -- we are typically a Standard Edition shop, for example, thanks to low budgets.

If the client wants a higher (perceived) uptime, or we have stricter constraints on maintenance windows, we'll run synchronous Database Mirroring between two servers, with a witness, all within the same LAN segment (don't try to do mirroring over the WAN). The witness component will run reasonably on an Express instance, on one of our VM hosts -- if you have no such host, you'll either want a cheap commodity server or you'll have to co-opt with another service (the number of domain controllers I've has to co-opt in my time, due to budget constraints, is laughable).

The witnessed mirror allows for a basic automatic failover should the primary die, and covers us if we need to manually take it down. At the exact point of failure, existing connections are still going to error out, but reconnection is usually successful.

It is possible to coordinate failover of multiple databases, by configuring alerts against the database mirroring WMI events and running a job to failover all databases, in response to that alert (but it is not immediate enough for any truly mission-critical stuff).

It is important to develop the connecting applications such that they are 'mirror-aware'. This is not particularly easy, but it helps if you can gracefully handle a dropped connection by automatically attempting reconnection; and can reduce any cross-databases dependencies in the system (particularly if modules in one database access objects in another -- you may have to look into abstracting these with linked servers whose connection strings include the Failover Partner tuple).

You should also make sure any Agent jobs are mirror-aware, by at least checking to see if the database is primary before you run your job steps.

If the client wants an offsite DR, we'll run log shipping to our secondary location, accepting the latency of data between the primary and recovery sites. We modify our log-shipping processes from the standard, by configuring the target share as \\localhost\LogShipping, rather than a dedicated NAS. By creating the share on both database servers, we can control the transfer rate of the log-ship (lookup: robocopy /ipg), so we don't flood our WAN.

As far as failover goes, our switch from primary to secondary site is always backed by a conscious, manual decision. There are always additional components to failover (e.g. connecting apps to re-point, users to inform) and the 'cost' of this is often higher than simply fixing the outage on the primary site. As such, automatic failover between sites is not a priority for us.

We do, however, have clients who believe they want the uptime and the recovery, for whom we tend to do a two-onsite-one-offsite setup combining the techniques described above. It's a pain to setup but it works well once it is.

Documentation is key, here. The important thing for us is making everyone aware what the limitations of the solution are -- the developers have to buy in and work as hard as they can to make their applications resilient to the idiosynchrases of the environment; and the client has to buy in, and not overestimate the resilience of the solution (if they do, you should be able to clearly show that they were informed of, and signed off on the limitations). It's not something we can always convey to our salespeople, mind!

Once you properly explain the expense of true high-availability (in both monetary and development-complexity terms) and let the business sponsors battle it out between them, you should find that some of your constraining factors are relaxed (be that, more budget allocated for hardware and/or development, or the RTO/RDO requirements for high-availability are relaxed).

Good luck.

J