¿Cuál es la mejor manera de determinar cuándo es apropiado usar una base de datos?

Comencé mi carrera de programación en desarrollo web usando PHP y MySQL. Me acostumbré bastante a utilizar db para el almacenamiento de la mayoría de los datos dinámicos, así como algunos datos de configuración / parámetros. Algunas veces habría muchos datos, mientras que otras veces las entradas en las tablas serían pocas. Para mí, esto parecía natural y, hasta donde yo sé, este es un enfoque más o menos aceptable en el desarrollo web. (Por favor corrígeme si estoy equivocado...)

Ahora estoy profundizando en las aplicaciones de escritorio y mi inclinación natural es utilizar nuevamente una base de datos para almacenar una gran cantidad de información que se generará a través del uso de la aplicación. Sin embargo, por lo que puedo decir, no veo aplicaciones (que uso) que utilicen un db muy a menudo. [EDITAR: desde entonces se ha señalado que esta fue una suposición errónea en el sentido de que muchas aplicaciones usan dbs ligeros integrados en el programa mismo.] ¿Cuál es la razón de esto? ¿En qué punto es apropiado utilizar un db? ¿Hay alguna norma sobre este asunto? Además, ¿cuáles son las razones para NO usar un db para desarrollar una aplicación de escritorio?

si su aplicación está orientada a documentos, almacene cosas en un archivo de documento

Si su aplicación trata con datos más estructurados, demasiado para un solo documento (como un documento XML), use una base de datos

Tradicionalmente, un sistema de base de datos ha sido visto como un servicio relativamente pesado, que no necesariamente quería instalar en cada máquina cliente. De hecho, he estado en situaciones (desarrollo de aplicaciones GUI de escritorio en las que se necesitaban guardar muchos datos) en las que un sistema de base de datos real habría sido una solución "ideal", pero porque en el pasado las únicas bases de datos disponibles eran relativamente pesadas, fuimos con archivos de datos planos en su lugar.

A pesar de que actualmente existen algunas bases de datos más livianas, este sigue siendo un argumento válido contra las bases de datos del lado del cliente. Imagine una pequeña aplicación de escritorio simple (como, por ejemplo, un juguete o juego de escritorio simple) que tiene que almacenar algunas docenas de configuraciones y parámetros. Parece exagerado hacer que una persona instale MySQL solo para ejecutar su aplicación.

Con el desarrollo web, el servidor es naturalmente un back-end, donde tener una base de datos es parte del curso. p.ej. Los usuarios no tienen que preocuparse por instalar una base de datos al final.

Las aplicaciones de escritorio mantienen el estado mientras se ejecutan. Mientras que el desarrollo web generalmente no lo hace. Entonces, si bien es posible que deba almacenar una configuración de usuario en una base de datos entre cargas de página, en una aplicación de escritorio simplemente las guarda en la memoria. Eso reduce en gran medida la necesidad de este tipo de almacenamiento persistente. Cuando desee almacenar preferencias entre usos, puede guardarlos en un solo archivo o colocarlos en algún lugar como el registro de Windows.

Dicho esto, los sistemas de bases de datos se usan bastante en aplicaciones de escritorio. Mucho antes de la web, las aplicaciones de escritorio se habían conectado a DBMS. Principalmente para aplicaciones que no están basadas en documentos. Aunque en estos días, con la mejor disponibilidad de motores livianos, estás viendo las líneas un poco borrosas. Por ejemplo, utilizo bases de datos SQLite como documentos en algunas de mis aplicaciones.

Una cosa que quizás desee considerar son las bases de datos livianas que no requieren un servicio de base de datos en ejecución real. por ejemplo, en el frente de Microsoft está SQL Server Compact , que es gratuito, solo requiere un único archivo para la base de datos y algunas DLL agregadas a su aplicación, y desde la perspectiva del desarrollador, se comporta de la misma manera que un SQL Server "real".

Estoy seguro de que hay opciones similares en otras plataformas.

En las aplicaciones web, es importante almacenar cualquier estado persistente en un almacenamiento centralizado. Dado que la aplicación web suele ser el primer cuello de botella, es importante poder distribuirla sin tener que cuestionar qué copia tiene los datos (el principio de 'Nada Compartido'). No solo una base de datos, sino que los memcachedsistemas de colas están ahí por la misma razón.

Las aplicaciones de escritorio no tienen el mismo objetivo de escalabilidad. Por lo general, la mayoría de los datos se almacenan localmente en cada estación de trabajo. El intercambio de datos es un problema diferente en la mayoría de los casos. Eso elimina una gran razón para usar una base de datos.

Las aplicaciones GUI también pueden tener documentos complejos que podrían manejarse como una red compleja de objetos en la memoria. La normalización de la estructura en un esquema de base de datos relacional puede agregar una complejidad significativa al problema, a veces es más fácil simplemente serializar todo en una sola prueba. Muchos marcos de OOP incluyen algunas instalaciones solo para eso.

Aún así, hacer que los documentos almacenados sean legibles con herramientas fuera de la aplicación principal es una gran ventaja en muchos casos, por lo que usar formatos legibles por humanos (XML, JSON, YAML, etc.) o un archivo zip que amalgama varias piezas más simples es cada vez más fácil. más común.

En el mismo sentido, el uso de una biblioteca de base de datos incorporable (BDB, Tokyo Cabinet, SQLite, MS-SQL * server Compact, etc.) es otro gran enfoque.

Las bases de datos pueden ser excesivas, pero generalmente no tienen que serlo. Los programas muy simples simplemente no los necesitan. Si su documento puede cargarse en la memoria en un tiempo trivial y permanecer allí sin problemas, realmente no necesita uno para muchos programas.

Por ejemplo, considere:

#include "superheader.h"

int main()
{
    int row=2, column=2;
    DatabaseType db;
    db.ConnectTo("programDB", "user", "pass");
    db.setTable("messages");
    string hello_world=db.fetch(row, column);
    cout<<hello_world;
    return 0;
}

Bueno, eso es demasiado simplista, pero obviamente esto es demasiado. No tiene sentido tener ese nivel de gestión de datos para "Hello World"

Por lo general, la regla general que sigo es usar una base de datos si tiene muchos conjuntos de datos, especialmente si son únicos o usar una base de datos si la cantidad de datos es bastante masiva. Las bases de datos en general están asociadas con algunos gastos generales, pero hay muchos que realmente no tienen mucho. Las bases de datos pequeñas, livianas y en memoria, por ejemplo, a veces son útiles para proyectos pequeños con procesamiento pesado, programación o muchos cambios dinámicos en los datos.

Hay diferentes estilos de codificación, muchas veces no hay nada de malo en una base de datos, pero la mayoría de nosotros simplemente no iremos tan lejos para las tareas básicas. Todavía hay otras ocasiones en que la base de datos correcta ofrecería beneficios de rendimiento. Intente comprender especialmente las diferencias en dónde estarán los datos, cuánto tiempo estarán allí y qué los cambiará durante su vida útil.

Usar un db siempre es lo correcto y con las implementaciones de SQLite para prácticamente todos los idiomas que no se usan, solo se toma una mala decisión de diseño. La única razón para no usar uno es si está haciendo programación incrustada o algún otro tipo de programación sin aplicación. Consultar datos y configuraciones con un lenguaje declarativo como SQL es mucho más natural que atravesar archivos planos u otros objetos en la memoria con una sintaxis imperativa. Además, separa limpiamente las operaciones de datos de otro código de aplicación que a la larga hace que el código sea más modular y fácil de mantener.