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

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

Si la 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 desea instalar en cada máquina cliente. De hecho, he estado en situaciones (desarrollo de aplicaciones de GUI de escritorio donde se necesitaba guardar una gran cantidad de datos) donde un sistema de base de datos real hubiera sido una solución "ideal", pero como 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 existen bases de datos más livianas en estos días, este es un argumento válido contra las bases de datos del lado del cliente. Imagine una pequeña aplicación de escritorio simple (como un juguete o juego de escritorio simple) que tiene que almacenar unas pocas docenas de configuraciones y parámetros. Parece muy exagerado hacer que una persona instale MySQL solo para ejecutar tu 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 en su extremo.

Las aplicaciones de escritorio mantienen el estado mientras se ejecutan. Mientras que el desarrollo web normalmente no lo hace. Por lo tanto, si bien es posible que necesite almacenar una configuración de usuario en una base de datos entre cargas de página, en una aplicación de escritorio, simplemente los guarda en la memoria. Eso reduce en gran medida la necesidad de tales tipos de almacenamiento persistente. Cuando desee almacenar las preferencias entre usos, puede guardarlas todas en un archivo o ubicarlas en algún lugar como el registro de Windows.

Dicho esto, los sistemas de bases de datos se utilizan bastante en las aplicaciones de escritorio. Mucho antes de la web, las aplicaciones de escritorio se han 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, se ven las líneas borrosas un poco. Por ejemplo, uso los documentos como de SQLite db en algunas de mis aplicaciones.

Una cosa que debería considerar son las bases de datos ligeras que no requieren un servicio de base de datos en ejecución real. p.ej. en el frente de Microsoft hay SQL Server Compact , que es gratuito, solo requiere una El archivo para la base de datos y algunos DLL agregados a su aplicación, y desde la perspectiva de un desarrollador, se comporta de la misma manera que un servidor SQL "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. Como 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, pero memcached y los sistemas de colas están ahí por la misma razón.

Las aplicaciones de escritorio no tienen el mismo objetivo de escalabilidad. Normalmente, 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 pueden 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 un solo bytestream. Muchos marcos OOP incluyen algunas facilidades solo para eso.

Sin embargo, 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 para las personas (XML, JSON, YAML, etc.) o un archivo zip que amalgama varias piezas más simples son cada vez más común.

En la misma línea, 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 por lo general no tienen que ser . Los programas muy simples simplemente no los necesitan. Si su documento se puede cargar en la memoria en una cantidad de tiempo trivial y permanecer allí sin problemas, realmente no necesita uno para muchos programas.

Por ejemplo considera:

#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 realmente tener ese nivel de administración de datos para "Hello World"

Por lo general, la regla de oro que utilizo es usar una base de datos si tiene muchos conjuntos de datos, especialmente si son únicamente diferentes O O use una base de datos si la cantidad de De los datos es bastante masivo. Las bases de datos en general están asociadas con cierta sobrecarga, pero hay muchas que realmente no tienen mucho. Las bases de datos pequeñas, ligeras y en memoria, por ejemplo, a veces son útiles para proyectos pequeños con un gran procesamiento, 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 no vamos a ir tan lejos para tareas básicas. Todavía hay otras veces que la base de datos derecha ofrecería beneficios de rendimiento. Trate de comprender especialmente las diferencias en cuanto a dónde estarán los datos, cuánto tiempo estarán allí y qué los cambiarán durante su vida útil.

Usar una base de datos siempre es lo correcto y, con las implementaciones de SQLite para prácticamente todos los idiomas, no usar una es simplemente una mala decisión de diseño. La única razón para no usar uno es si está haciendo programación integrada o algún otro tipo de forma de programación que no sea de 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 las operaciones de datos de otro código de aplicación, lo que a la larga hace que el código sea más modular y fácil de mantener.