¿Tiene sentido usar un servidor de base de datos si la aplicación solo hace cosas localmente?

SQLite ofrece un buen resumen de cuándo usarlo o no vs alternativas:

enlace

Esta línea de resumen captura el caso de uso de SQLite extremadamente bien en mi experiencia:

  

SQLite no compite con las bases de datos cliente / servidor. SQLite compite con fopen ().

El artículo se expande extensamente en este punto. También tiene una sección titulada "Situaciones en las que un cliente / servidor RDBMS puede funcionar mejor". En pocas palabras, son:

• Aplicaciones cliente / servidor : múltiples usuarios en una red.
• Sitios web de gran volumen : ya sea de escritura intensiva o de lectura lo suficientemente intensiva como para requerir fragmentación.
• Conjuntos de datos muy grandes : más grandes que los que se pueden almacenar razonablemente en un disco.
• Alta concurrencia : en particular, escrituras concurrentes.

Incluso para un solo sistema con un solo usuario, un servidor de base de datos "real" tiene sentido:

1. Utiliza un lenguaje familiar ( SQL ). SQLite utiliza SQL, pero algunas bases de datos incrustadas (por ejemplo, base de datos de objetos , NoSQL ) no utilizan SQL. Estos tienden a tener una curva de aprendizaje más alta porque son menos comunes.
2. Proporciona integridad referencial, restricciones, desencadenadores, etc. que los productos como SQLite pueden no proporcionar o al menos no proporcionar en su totalidad.
3. Al dirigirse a un verdadero multiusuario, ACID base de datos de red, la aplicación tiene la opción de trabajar en una sola escenario de usuario / estación de trabajo individual, o como aplicación alojada multiusuario utilizando el mismo código base .
4. El usuario tiene la capacidad de examinar los datos fuera de línea utilizando herramientas estándar (p. ej., SQL Developer, MySQL Workbench, SQL Server Management Studio), cargar o realizar copias de seguridad de los datos utilizando esas herramientas, etc. Aunque es posible hacerlo con muchas aplicaciones integradas bases de datos de varios tipos, las personas tal vez estén más familiarizadas con esas herramientas del mundo de bases de datos C / S.

El principal inconveniente es la necesidad de instalar y mantener el software del servidor de base de datos, que es un poco complejo para los usuarios no técnicos (e incluso muchos usuarios técnicos). Los sistemas operativos como Linux lo hacen más fácil: tengo PostgreSQL y MySQL ejecutándose en mi sistema Linux. He instalado aplicaciones que se enganchan en ellas con poca o ninguna interacción por mi parte.

Creo que tiene que ver con la inercia.

Amarok se basa en XMMS, que es de 1997. Para tener que tener buenas capacidades de base de datos, tenía que usar un servidor, porque era mucho más potente que las soluciones basadas en archivos, que en ningún caso significa tenía buenas capacidades de base de datos.

La próxima y creciente popularidad de buenas bases de datos incrustadas locales como SQLlite es algo bastante reciente.

La característica discriminatoria más importante es concurrencia .

Si solo tiene una aplicación que se ejecuta en una instancia para el usuario, la solución integrada (ya sea sqlite o algún almacenamiento de objetos) generalmente está bien.

Sin embargo, si tiene varias instancias que necesitan manipular la base de datos al mismo tiempo, necesita tener un servidor para sincronizarla. SQLite solo permite una escritura a la vez, en toda la base de datos, al igual que la mayoría de las otras soluciones integradas. Y si incluso tiene varias aplicaciones, es probable que necesite una especificación de restricción más detallada que las soluciones integradas generalmente tampoco permiten.

Muchas de las otras respuestas hablan de la concurrencia como una ventaja, pero también como la base de datos se ejecuta como un servidor, la base de datos puede ejecutar tareas sin necesidad de que la aplicación se ejecute. Esto podría ser mantenimiento, copias de seguridad, sincronización con otro servidor o cualquiera de las tareas programadas.

Si cree que su aplicación podría convertirse en una aplicación cliente / servidor, es posible que desee comenzar a usar un RDBMS desde el principio en lugar de trasladarlo más tarde.

No tengo idea si el ejemplo dado aprovecha esto o no.

A menos que esté ejecutando un sistema integrado con poca memoria y CPU, no creo que ejecutar un servidor en segundo plano le esté haciendo ningún daño.

Ejecutar un servidor de base de datos localmente está bien. La base de datos está destinada a acceder y manipular los datos. El acceso a la red es una ventaja, que puede o no ser necesaria. Hay algunas herramientas de ingeniería y científicas que hacen esto.

Supongamos que está utilizando datos, en una aplicación local. ¿Por qué no deberías usar una base de datos? a diferencia de qué?

Depende de la abstracción de sus datos y del espacio general de la aplicación, los requisitos de gestión de acceso, la inversión que está planeando para el mantenimiento de los datos, la urgencia del prototipo requerido, dónde se encuentra en la curva de aprendizaje, etc.

Si desea garantizar una base de datos estrechamente integrada a una aplicación que no requiera acceso desde otras aplicaciones, cree islas de bases de datos integradas. La implementación del almacenamiento web de Mozilla Firefox con SQLite se puede dar como ejemplo.

Si necesita aún más eficiencia con datos limitados, es preferible una selección de diseño de bases de datos en memoria.

Por otra parte, si tiene muchas aplicaciones que ejecutan varias consultas en los mismos datos y requiere una mejor estructuración del almacenamiento de datos para optimizar el rendimiento, se requiere un DBMS centralizado. Absolutamente lo preferiré para la investigación científica, cuando requiera una gran cantidad de datos y donde el tiempo de respuesta de la consulta afectará drásticamente la experiencia general del usuario.

Para el caso de Amarok, supongo que era una selección de DBMS de código abierto en ese momento, antes de elegir la ruta de las bases de datos incrustadas.

Si hay una definición específica del sistema en tu mano, será más fácil ponderar los pros y los contras.

V / r, Umut