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

41

Eu já vi alguns aplicativos que são basicamente softwares aplicativos executados localmente no sistema (para que eles não se comuniquem muito pela rede). Esses aplicativos parecem depender dos servidores de banco de dados para armazenar seus dados.

Um exemplo de aplicativo é o Amarok (um popular tocador de música no Linux). Não sei se eles ainda fazem isso, mas lembro que houve um tempo em que instalar o Amarok significava que era necessário instalar um servidor MySQL e executá-lo em segundo plano o tempo todo.

Qual é a vantagem de usar um servidor para armazenamento local em comparação com o uso de uma solução SQL incorporada menor, como o sqlite? Estou falando de software de aplicativo em geral, não necessariamente amarok (isso foi apenas um exemplo). Existem situações em que o uso de um servidor de banco de dados faz sentido em comparação com um banco de dados incorporado?

database applications

— 9a3eedi
fonte

4

Ter um banco de dados pode ser muito importante. Ter um banco de dados em processo ou um banco de dados em processo separado é uma opção / detalhe da implementação.

— 9000

2

Eu entendi aquilo. A questão é mais sobre por que você escolheria um banco de dados de processo separado (como servidor mysql) em vez de um banco de dados em processo (como SQLite) para aplicativos locais.

— 9a3eedi

29

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

https://www.sqlite.org/whentouse.html

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

O SQLite não compete com os bancos de dados cliente / servidor. SQLite compete com fopen ().

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

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

— Denis de Bernardy
fonte

@ 9a3eedi: na verdade, entre esses quatro pontos, não há nenhum que descreva um cenário com um servidor de banco de dados completo em combinação com o armazenamento local (especialmente os dois primeiros são exatamente o oposto disso) - então, você poderia nos esclarecer por que escolheu isso? resposta, embora não se encaixe na sua pergunta original? A propósito, dei uma resposta negativa a essa resposta exatamente por esse motivo.

— Doc Brown

@DocBrown: casos específicos em que você deve usar um RDBMS cliente / servidor são [ver resposta]; para todo o resto, o SQLite funciona bem. Não tenho certeza do que não está claro, por isso, sinta-se à vontade para editar a resposta, se achar necessário.

— Denis de Bernardy

A pergunta original era sobre casos específicos em que o banco de dados ac / s faz sentido se o aplicativo fizer apenas as coisas localmente (citar o título) ou usar um servidor para armazenamento local (citar o texto da pergunta). Os quatro cenários acima são exatamente o oposto deles (os dois primeiros) ou muito improváveis ou incomuns como cenários "locais" (os dois primeiros). Portanto, o que você escreveu não está errado, mas não se encaixa na pergunta.

— Doc Brown

@DocBrown - e a resposta curta é: não faz sentido, a menos que você esteja lidando com conjuntos de dados extragrandes ou com necessidade de gravações simultâneas. (Ou, por razões óbvias, na necessidade de algo que o SQLite não ofereça.) Novamente, fique à vontade para editar a resposta se esse ponto não estiver claro para você.

— Denis de Bernardy

Bem, se você realmente acha que a lista está completa (e fornece uma declaração oculta de que, para um cenário local, o uso de um servidor de banco de dados C / S não faz sentido), discordo e não acho que posso melhorar sua resposta adicionando alguns esclarecimentos.

— Doc Brown

28

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

Ele usa uma linguagem familiar ( SQL ). O SQLite usa SQL, mas alguns bancos de dados incorporados (por exemplo , banco de dados de objetos , NoSQL ) não usam SQL. Aqueles tendem a ter uma curva de aprendizado mais alta porque são menos comuns.
Ele fornece integridade referencial, restrições, gatilhos, etc., que produtos como o SQLite podem não fornecer ou pelo menos não fornecer na íntegra.
Ao direcionar um verdadeiro banco de dados de rede compatível com ACID e multiusuário, o aplicativo tem a opção de trabalhar em um cenário de usuário único / estação de trabalho única ou como um aplicativo hospedado multiusuário usando a mesma base de código .
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 bancos de dados incorporados de vários tipos, as pessoas talvez estejam mais familiarizadas com essas ferramentas do mundo dos bancos de dados C / S.

A principal desvantagem é a necessidade de instalar e manter o software do servidor de banco de dados, um pouco complexo para usuários não técnicos (e até muitos usuários técnicos). Sistemas operacionais como o Linux facilitam isso: Eu tenho o PostgreSQL e o MySQL em execução no meu sistema Linux. Instalei aplicativos que se ligavam a eles com pouca ou nenhuma interação da minha parte.

— Doc Brown
fonte

9

Na verdade, existe um sistema de banco de dados (Sybase SQL Anywhere) com suporte completo a SQL, integridade referencial, ACID, procedimentos armazenados, que não requerem configuração do servidor ou instalação como serviço quando executados em uma configuração local (embora possa ser configuração para um ambiente multiusuário). Eu não sei qualquer outro sistema de banco de dados com essas propriedades, se alguém conhece um, eu estaria interessado em.

— Doc Brown

3

O @DocBrown IIRC MS SQLServer Compact oferece isso como uma dll, embora o LocalDB seja provavelmente a melhor opção - ele não requer instalação como serviço, mas requer direitos de administrador.

— Gbjbaanb

5

Para adicionar à discussão de validade da desvantagem - além do SQLite, curiosamente já mencionado na resposta, vários bancos de dados não-SQL e sistemas semelhantes a bancos de dados, por exemplo, OrientDB, Solr e outros, têm suporte dedicado à incorporação .

— Mikołak

14

O SQLite fornece integridade referencial (embora precise ser ativada) e restrições básicas. Também é significativamente mais rápido que a maioria dos servidores, se usado corretamente. A principal desvantagem em comparação com o servidor é o fato de ser um escritor único.

— Jan Hudec

2

@DocBrown: o banco de dados incorporado do Firebird fornece suporte SQL completo, incluindo integridade referencial, garantias ACID, procs armazenados e gatilhos. Ele não era usado para oferecer suporte a várias conexões simultâneas com um banco de dados incorporado e não tenho certeza se essa limitação ainda está em vigor ou não, mas todo o conjunto de recursos SQL está lá.

— Mason Wheeler

21

Eu acho que tem a ver com inércia.

O Amarok é baseado no XMMS, que é de 1997. Para ter boas capacidades de banco de dados, era necessário usar um servidor, porque era muito mais poderoso do que as soluções baseadas em arquivos, que de modo algum tinham boas capacidades de banco de dados.

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

— Pieter B
fonte

Pelo que me lembro, o AmaroK 1 (que pode ter sido baseado no XMMS) não dependia de um servidor de banco de dados. Foi Amarok 2, que foi lançado com KDE4 que introduziu a dependência, e no momento eu achei muito estranho que eles iriam me necessita para MySQL instalar e mantê-lo funcionando em segundo plano

— 9a3eedi

10

O recurso discriminante mais importante é a simultaneidade .

Se você tiver apenas um aplicativo que é executado em uma instância para o usuário, a solução incorporada (seja sqlite ou algum armazenamento de objeto) normalmente está OK.

No entanto, se você tiver várias instâncias que precisem manipular o banco de dados simultaneamente, precisará de um servidor para sincronizá-lo. O SQLite permite apenas uma gravação de cada vez, em todo o banco de dados, assim como 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.

— Jan Hudec
fonte

5

Muitas das outras respostas falam sobre simultaneidade como uma vantagem, mas também como o banco de dados está sendo executado como servidor, o banco de dados pode executar tarefas sem a necessidade do aplicativo em execução. 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 faço ideia se o exemplo dado tira proveito disso ou não.

— JeffO
fonte

2

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

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

Digamos que você esteja usando dados em um aplicativo local. Por que você não deveria usar um banco de dados? em oposição a quê?

— cauchy
fonte

Se eu fosse implantar um aplicativo para usuários normais (digamos, um tocador de música como o AmaroK), eu pensaria que tê-los instalando o servidor MySQL e rodando em segundo plano é um requisito de sistema um pouco demais e será algo que os usuários usariam não parece. Mas acho que depende da aplicação. É o contrário de usar algo como SQLite.

— 9a3eedi

2

Depende da abstração dos dados e do espaço geral do aplicativo, dos requisitos de gerenciamento de acesso, do investimento que você planeja manter, da urgência do protótipo necessário, da localização da curva de aprendizado etc.

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

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

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

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

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

V / r, Umut

— Umut Kahramankaptan
fonte