O uso de um servidor de banco de dados faz sentido se o aplicativo faz apenas coisas localmente?

SQLite oferece um bom resumo de quando usá-lo ou não vs alternativas:

link

Esta linha de resumo captura extremamente bem o caso de uso do SQLite na minha experiência:

SQLite does not compete with client/server databases. SQLite competes with fopen().

O artigo se expande longamente neste ponto. Ele também tem uma seção intitulada "Situações em que um cliente / servidor RDBMS pode funcionar melhor". Em poucas palavras, eles são:

• Aplicativos cliente / servidor : vários usuários em uma rede.
• Websites de alto volume : escreva intensivamente ou leia com intensidade suficiente para exigir fragmentação.
• Conjuntos de dados muito grandes : maiores do que podem ser razoavelmente armazenados em um disco.
• Alta simultaneidade : em particular, gravações simultâneas.

Mesmo para um único sistema com um único usuário, um servidor de banco de dados "real" faz sentido:

1. Ele usa uma linguagem familiar ( SQL ). O SQLite usa o SQL, mas alguns bancos de dados incorporados (por exemplo, banco de dados de objetos , NoSQL ) não usam SQL. Esses tendem a ter uma curva de aprendizado mais alta porque são menos comuns.
2. Ele fornece integridade referencial, restrições, disparadores, etc., que produtos como o SQLite podem não fornecer ou pelo menos fornecer não totalmente.
3. Ao segmentar um verdadeiro banco de dados de rede compatível com vários usuários, ACID , o aplicativo tem a opção de trabalhar em um único cenário de usuário / estação de trabalho única ou como um aplicativo hospedado por vários usuários usando a mesma base de código .
4. O usuário tem a capacidade de examinar os dados offline usando ferramentas padrão (por exemplo, SQL Developer, MySQL Workbench, SQL Server Management Studio), carregar ou fazer backup de dados usando essas ferramentas etc. Embora seja possível fazer isso com muitos recursos incorporados bancos de dados de vários tipos, pessoas talvez mais familiarizadas com essas ferramentas do mundo de banco de dados do C / S.

A principal desvantagem é a necessidade de instalar e manter o software do servidor de banco de dados, o que é um pouco complexo para usuários não técnicos (e até mesmo para muitos usuários técnicos). Sistemas operacionais como o Linux tornam isso mais fácil: eu tenho PostgreSQL e MySQL rodando no meu sistema Linux. Eu instalei aplicativos que os conectavam com pouca ou nenhuma interação da minha parte.

Eu acho que tem a ver com inércia.

O Amarok é baseado no XMMS que é de 1997. Para ter recursos de banco de dados bons você tinha que usar um servidor, porque era muito mais poderoso do que as soluções baseadas em arquivos, que não significa ter boas capacidades de banco de dados.

A próxima e crescente popularidade de bons bancos de dados incorporados locais como o SQLlite é algo bastante recente.

O recurso discriminativo mais importante é a simultaneidade .

Se você tem apenas um aplicativo que é executado em uma instância para o usuário, a solução incorporada (seja o sqlite ou algum armazenamento de objetos) geralmente é aceitável.

No entanto, se você tiver várias instâncias que precisam manipular o banco de dados simultaneamente, é necessário ter um servidor para sincronizá-lo. O SQLite permite apenas uma gravação por vez, em todo o banco de dados, e a maioria das outras soluções incorporadas. E, se você tiver vários aplicativos, provavelmente precisará de especificações de restrições mais detalhadas que as soluções incorporadas geralmente não permitem.

Muitas das outras respostas falam sobre a simultaneidade como uma vantagem, mas também como o banco de dados está sendo executado como um servidor, o banco de dados pode executar tarefas sem a necessidade de execução do aplicativo. Isso pode ser manutenção, backups, sincronização com outro servidor ou qualquer tarefa agendada.

Se você acha que seu aplicativo pode se transformar em um aplicativo cliente / servidor, convém começar usando um RDBMS desde o início, em vez de transferi-lo mais tarde.

Não tenho ideia se o exemplo dado tira proveito disso ou não.

A menos que você esteja executando um sistema embarcado com pouca memória e cpu, não acho que executar um servidor em segundo plano esteja causando nenhum dano.

Executar um servidor de banco de dados localmente é bom. O banco de dados é destinado a acessar e manipular dados. O acesso à rede é uma vantagem, que pode ou não ser necessária. Existem algumas ferramentas de engenharia e científicas que fazem isso.

Digamos que você esteja usando dados em um aplicativo local. Por que você não deveria usar um banco de dados? ao contrário de quê?

Depende da abstração de dados e do espaço geral do aplicativo, dos requisitos de gerenciamento de acesso, do investimento que você está planejando para a manutenção de dados, da urgência do protótipo necessário, de onde você está na curva de aprendizado etc.

Se você deseja garantir um banco de dados totalmente integrado a um aplicativo que não requer acesso de outros aplicativos, crie ilhas de banco de dados embutido. A implementação do Mozilla Firefox Web Storage com o SQLite pode ser fornecida como exemplo.

Se você precisar de ainda mais eficiência com dados limitados, uma seleção de design de bancos de dados na memória é preferível.

Por outro lado, se você tiver muitos aplicativos executando várias consultas nos mesmos dados e exigir uma melhor estruturação do armazenamento de dados para otimizar o desempenho, será necessário um DBMS centralizado. Eu irei absolutamente preferir isso para pesquisa científica, quando ela exigir uma grande quantidade de dados e onde o tempo de resposta da consulta irá impactar drasticamente a experiência geral do usuário.

Para o caso do Amarok, acho que foi uma seleção de DBMS de código aberto na época, antes de escolher o caminho dos bancos de dados incorporados.

Se houver uma definição de sistema específica à sua mão, será mais fácil ponderar os contras e os profissionais.

V / r, Umut