¿Por qué SQL no está tan extendido en grandes aplicaciones de escritorio?

Como desarrollador de software, he trabajado en proyectos que van desde pequeñas aplicaciones caseras hasta aplicaciones empresariales medianas. En casi todos los proyectos utilicé una base de datos o lamenté no utilizarla desde el principio.

Ahora, me pregunto algunas cosas sobre las bases de datos y su uso en aplicaciones generales:

• ¿Por qué Windows no utiliza ninguna base de datos SQL "central"? Por ejemplo:
  • Los datos de informes de errores se almacenan en un montón de archivos,
  • Windows Update almacena todo en archivos planos,
  • La caché de iconos se almacena en un archivo único muy extraño al que no parece accederse a través de SQL, etc.
• ¿Por qué tantas aplicaciones grandes evitan usar bases de datos? Por ejemplo, ¿no ganaría Microsoft Outlook usando una base de datos real en lugar de reinventar la rueda al tener su propio formato para archivos .pst y almacenar algunos datos en el registro?

Si la base de datos agrega una capa adicional de una complejidad general y una pequeña pérdida de rendimiento, es una gran ventaja el hecho de simplificar el código en la mayoría de las circunstancias, especialmente cuando se trata del almacenamiento de pequeños fragmentos organizados de datos en lugar de grandes binarios. corrientes. Entonces, ¿por qué tan pocos productos utilizan bases de datos? ¿Probablemente la única aplicación que conozco que realmente utiliza la base de datos Sqlite es Firefox y tal vez Microsoft Exchange (pero la última no es una aplicación de escritorio)?

Además, un conjunto de aplicaciones, como Microsoft Office o Microsoft Expression, no se beneficiaría de tener una base de datos SQL unificada , lo que hace que sea más fácil implementar las aplicaciones, actualizar / actualizar los datos, compartir datos entre esas aplicaciones, hacer copias de seguridad ¿etc.?

1) En términos generales, la sobrecarga de ejecutar un RDBMS completo es demasiado grande y agregaría una carga innecesaria al sistema y la complejidad.

Tener uno instalado facilita su vida como desarrollador, pero empeora la vida del propietario de la máquina, ya que es probable que su máquina funcione más lentamente y con más problemas. En las confrontaciones entre desarrollador y usuario, el usuario casi siempre debe ganar.

2) Muchos almacenes de datos tienen necesidades específicas que no son satisfechas por algo como SQL Server Express.

Por ejemplo, los registros de errores deben escribirse de la manera más simple posible para maximizar la posibilidad de que ocurra la escritura y los datos estén disponibles. SQL Server nunca será tan simple.

Para aplicaciones más complejas, el argumento tiende a centrarse más en la optimización para casos de usuarios muy específicos: los archivos planos pueden ser muy rápidos.

Muchas aplicaciones incorporan SQLite . Citando desde su sitio web:

SQLite es una biblioteca de software que implementa un motor de base de datos SQL transaccional autónomo, sin servidor, de configuración cero. SQLite es el motor de base de datos SQL más implementado en el mundo. El código fuente de SQLite está en el dominio público ".

Simplemente use una de las API disponibles, cree una base de datos, tablas, etc. y el motor SQL almacenará todo en un archivo binario que puede colocar en cualquier lugar dentro del sistema de archivos del usuario. Lo mejor de todo, es FLOSS.

Windows se entrega y utiliza un motor de base de datos llamado Extensible Storage Engine (ESE) .

ESE es utilizado por Active Directory, Exchange Server, Windows Mail y Desktop Search entre muchos otros servicios y aplicaciones de Windows.

Para el desarrollo, existen contenedores ESE de código abierto:

• Kit de herramientas ESE C # / C ++ 1.2
• ManagedEsent para .NET

Con el envío de ESE con cada versión moderna de Windows, no tiene problemas de implementación de bases de datos. Arquitectónicamente, ESE cumple una función similar a las bases de datos integradas como SQLite.

Las bases de datos relacionales no son la estructura de datos más eficiente para cada dominio. Muchas aplicaciones de escritorio usan bases de datos integradas, simplemente no se puede decir fácilmente que lo están haciendo si todo lo que ves son un par de archivos de datos.

¿Por qué Windows no utiliza ninguna base de datos SQL "central"?

En realidad, esta idea ha estado en desarrollo en Microsoft por algún tiempo. Se llama WinFS . Es una tecnología intrigante y está disponible para los suscriptores de MSDN. Algunos días pronto, lo instalaré en una máquina virtual y jugaré con él.

Las bases de datos ofrecen flexibilidad y, como todas las funciones, es casi seguro que haya un costo. Si un archivo plano funcionará, puede suponer que nadie necesitará consultar los datos de manera inesperada, como en un informe ad hoc.

Las bases de datos también hacen un buen trabajo al manejar múltiples conexiones / entradas. Nuevamente, si esto no es un requisito para su aplicación de escritorio, ¿por qué agregar la complejidad adicional? Además de a través de la interfaz de usuario / la instalación real de Outlook, ¿cuántas otras aplicaciones o usuarios están tratando de escribir en el archivo de Outlook en su computadora?

Sería más fácil si todos los datos estuvieran en una base de datos relacional desde una perspectiva de "Quiero poder consultar todos los datos de cualquier manera que considere adecuada con un solo lenguaje como SQL", pero esto rara vez es una prioridad con muchas aplicaciones.

La mayoría de los programadores lo verán desde:

• Sé lo que se supone que debe hacer la aplicación, esto es todo lo que se supone que debe hacer

• mi aplicación es la única entidad que accederá y / o manipulará estos datos

• una estructura de archivo simple de mi propio diseño funcionará

• para al menos una aplicación, me gustaría evitar depender del código de otras personas y tener un control completo.