Perché SQL non è così diffuso nelle applicazioni desktop di grandi dimensioni?

Come sviluppatore di software, ho lavorato su progetti che vanno dalle piccole app fatte in casa alle applicazioni aziendali di medie dimensioni. In quasi tutti i progetti ho usato un database o mi sono pentito di non averlo usato fin dall'inizio.

Ora, mi chiedo alcune cose sui database e sul loro utilizzo in applicazioni generali:

• Perché Windows stesso non utilizza alcun database SQL "centrale"? Per esempio:
  • I dati relativi alla segnalazione degli errori sono memorizzati in un mucchio di file,
  • Windows Update archivia tutto in file flat,
  • La cache delle icone è memorizzata in un singolo file molto strano a cui non sembra accedere tramite SQL, ecc.
• Perché così tante applicazioni di grandi dimensioni evitano di usare database? Ad esempio, Microsoft Outlook non guadagnerebbe utilizzando un vero database invece di reinventare la ruota avendo il proprio formato per i file .pst e archiviando alcuni dati nel registro?

Se il database aggiunge un ulteriore livello di una complessità complessiva e una piccola perdita di prestazioni, è un prezzo di un enorme vantaggio di semplificare il codice nella maggior parte dei casi, soprattutto quando si tratta di archiviare piccoli blocchi di dati organizzati anziché grandi binari flussi. Allora perché così pochi prodotti utilizzano effettivamente i database? Probabilmente l'unica applicazione che conosco che utilizza effettivamente il database Sqlite è Firefox e forse Microsoft Exchange (ma l'ultima non è un'applicazione desktop)?

Inoltre, un insieme di applicazioni, come Microsoft Office o Microsoft Expression, non trarrebbe vantaggio dall'avere un database SQL unificato , rendendo più semplice la distribuzione delle applicazioni, l'aggiornamento / l'aggiornamento dei dati, la condivisione dei dati tra tali applicazioni, per eseguire i backup , eccetera.?

1) In generale, l'overhead dell'esecuzione di un RDBMS completo è troppo elevato e aggiungerebbe inutili carichi al sistema e alla complessità.

Avere uno installato ti semplifica la vita come sviluppatore ma peggiora la vita del proprietario della macchina poiché è probabile che la sua macchina funzioni più lentamente e con più problemi. Nel confronto tra sviluppatore e utente, l'utente dovrebbe quasi sempre vincere.

2) Molti archivi di dati hanno esigenze specifiche che non sono soddisfatte da qualcosa come SQL Server Express.

Ad esempio, i registri degli errori dovrebbero essere scritti nella cosa più semplice possibile per massimizzare le possibilità che la scrittura avvenga e che i dati siano disponibili. SQL Server non sarà mai così semplice.

Per applicazioni più complesse l'argomento tende ad essere più ottimizzato per casi utente molto specifici: i file flat possono essere velocissimi.

Molte applicazioni incorporano SQLite . Citando dal loro sito Web:

SQLite è una libreria software che implementa un motore di database SQL transazionale autonomo, senza server, a configurazione zero. SQLite è il motore di database SQL più diffuso al mondo. Il codice sorgente per SQLite è di dominio pubblico. ".

Basta usare una delle API disponibili, creare un database, tabelle, ecc. E il motore SQL memorizzerà tutto in un file binario che è possibile inserire ovunque nel file system dell'utente. La cosa migliore è FLOSS.

Windows viene fornito con e utilizza un motore di database denominato Extensible Storage Engine (ESE) .

ESE è utilizzato da Active Directory, Exchange Server, Windows Mail e Desktop Search tra molti altri servizi e applicazioni Windows.

Per lo sviluppo, esistono wrapper ESE open source:

• Toolkit ESE C # / C ++ 1.2
• ManagedEsent per .NET

Con la spedizione ESE con tutte le versioni moderne di Windows non hai problemi di distribuzione del database. Architettonicamente ESE ricopre un ruolo simile ai database incorporati come SQLite.

I database relazionali non sono la struttura di dati più efficiente per ogni dominio. Molte applicazioni desktop utilizzano database incorporati, non si può facilmente dire che lo stanno facendo se tutto ciò che vedi sono un paio di file di dati.

Perché Windows stesso non utilizza alcun database SQL "centrale"?

In realtà, questa idea è stata in sviluppo in Microsoft per un po 'di tempo. Si chiama WinFS . È una tecnologia intrigante ed è disponibile per gli abbonati MSDN. Alcuni giorni presto lo installerò su una VM e ci giocherò.

I database offrono flessibilità e, come ogni caratteristica, quasi certamente hanno un costo. Se un file flat funzionerà, allora puoi presumere che nessuno avrà bisogno di interrogare i dati in modi imprevisti come in un rapporto ad hoc.

I database fanno anche un buon lavoro nella gestione di più connessioni / input. Ancora una volta, se questo non è un requisito per l'app desktop, perché aggiungere ulteriore complessità? Oltre all'interfaccia utente / all'installazione effettiva di Outlook stesso, quante altre applicazioni o utenti stanno tentando di scrivere sul file Outlook sul computer?

Sarebbe più semplice se tutti i dati si trovassero in un database relazionale dal punto di vista "Voglio essere in grado di interrogare tutti i dati nel modo che ritengo adatto a una singola lingua come SQL", ma raramente è una priorità per molte applicazioni.

La maggior parte dei programmatori lo guarderà da:

• So cosa dovrebbe fare l'app, questo è tutto ciò che dovrebbe fare

• la mia app è l'unica entità che potrà mai accedere e / o manipolare questi dati

• una semplice struttura di file di mia progettazione funzionerà

• per almeno un'applicazione vorrei evitare di fare affidamento sul codice di altre persone e avere il controllo completo.