Come posso progettare un'applicazione in modo che funzioni bene con un database selezionato dal cliente?

La risposta per usare un ORM che ti permette di astrarre quella via dai database stessi. NHibernate è il primo che viene in mente, sebbene EF sia una scelta accettabile se esiste un adattatore per i DB di cui hai bisogno. Non sono sicuro di quanto sia buono il supporto per DB2, ma SQL Server e Oracle funzionano correttamente.

Come stored procedure e trigger: non li usano. Non appena hai bisogno di spostare qualsiasi logica nel database, sei bloccato a gestirli in tutti i database che supporti. Se riesci a consentire a qualsiasi logica che vive nel livello applicazione dietro un'astrazione (NHibernate), puoi farla franca con il framework che esegue la traduzione per te. HQL ti permetterà di scrivere query come SQL per NHibernate che sono un'astrazione e se necessario.

Se ti attieni alle funzionalità fornite da Entity Framework, dovresti essere OK per SQL Server e supporto Oracle, e probabilmente anche DB2.

Vorrei tuttavia notare che non si tratta di una questione di dialetti SQL diversi. Avete considerato i diversi modelli di sicurezza di questi database? Hai pensato a come manterrai i tuoi script di database? Avrai degli ambienti di test per tutti questi database? Come genererai le metriche di dimensionamento, in modo che i clienti sappiano quanto si aspetta l'utilizzo del disco? Lavoro per un negozio di software piuttosto grande e non supportiamo nessun database che non è necessario, solo a causa di tutto il sovraccarico che comporta.

Puoi e dovresti astrarre il tuo livello dati. Tuttavia, prima di decidere arbitrariamente che il tuo scopo è quello di supportare più database, devi rendertene conto:

1. Tutti i database hanno i loro capricci e si comportano in modi diversi, quindi anche se si utilizza un ORM (il framework di entità è OK, ma non sono convinto di quanto sia buono per grandi volumi di dati) è necessario essere consapevoli che potrebbe non funzionare in modo identico per tutti i database (ad esempio le transazioni distribuite potrebbero non essere supportate). Ciò consente di aumentare i costi di sviluppo, possibilmente considerevolmente, se si desidera fornire un'esperienza coerente su tutti i database.
2. Anche se ORM è Impressionante e fa tutto in modo identico in ogni database, devi comunque eseguire tutti i test di accettazione in ogni ambiente di database per confermare ciò che sicuramente aumenta i costi di QA.

Ora stai scrivendo un sito Web .NET, dal suono di esso per il mercato consumer, quindi sarà ospitato su una scatola da qualche parte come Godaddy con accesso a un database SQL Server come parte del pacchetto.

Dato che qual è il ritorno sull'investimento atteso dal supporto di qualsiasi altro database diverso da SQL Server?

Direi che solo se pensi che questa cifra sia positiva e in proporzione agli altri costi di sviluppo dovresti considerare di supportare più di un database e quindi supportare solo altri database una volta stabilito e stabile il tuo prodotto con SQL Server indietro fine e c'è una domanda definita dai tuoi clienti.

Devi usare ORM se vuoi rimanere ASCIUTTO e come @Travis ha indicato che dovresti usare NHibernate perché ha il supporto per tutti loro già preparati. Senza ORM si avrà l'accesso ai dati completamente nelle stored procedure e si scriveranno di nuovo tutti in ogni database o si avrà un assembly speciale di accesso ai dati per database con query e comandi definiti in dialetto SQL specifico per DB. ORM racchiude già questa funzionalità e utilizza un linguaggio di query universale tradotto in dialetto richiesto dal database.