Qual é a melhor maneira de determinar quando é apropriado usar um banco de dados?

Comecei minha carreira de programação em desenvolvimento web usando PHP e MySQL. Acostumei-me bastante a utilizar o db para armazenamento dos dados mais dinâmicos, bem como alguns dados de configuração / parâmetro. Às vezes, havia muitos dados, enquanto outras vezes as entradas nas tabelas eram poucas. Para mim, isso parecia natural e, até onde sei, é mais ou menos uma abordagem aceitável no desenvolvimento da web. (Por favor me corrija se eu estiver errado...)

Estou investigando aplicativos de desktop agora e minha inclinação natural é utilizar novamente um banco de dados para armazenar muitas informações que serão geradas através do uso do aplicativo. No entanto, até onde eu sei, não vejo aplicativos (que eu uso) utilizando um banco de dados com muita frequência. [EDIT: Desde então, foi apontado que essa era uma suposição incorreta, pois muitos aplicativos usam dbs leves incorporados ao próprio programa.] Qual é a razão disso? Em que momento é apropriado utilizar um db? Existem padrões sobre esse assunto? Além disso, quais são os motivos para NÃO usar um banco de dados para desenvolver um aplicativo de desktop?

se seu aplicativo for orientado a documentos, armazene itens em um arquivo de documento

se o aplicativo lida com dados mais estruturados, em excesso para um único documento (como um documento XML), use um banco de dados

Tradicionalmente, um sistema de banco de dados é visto como um serviço relativamente pesado - que você não necessariamente deseja instalar em todas as máquinas clientes existentes. Na verdade, eu já estive em situações (desenvolvimento de aplicativos GUI de desktop em que muitos dados precisavam ser salvos) em que um sistema de banco de dados real teria sido uma solução "ideal" - mas, como antigamente, os únicos bancos de dados disponíveis eram relativamente pesados, fomos com arquivos de dados simples.

Apesar de existir alguns bancos de dados mais leves por aí atualmente, esse ainda é um argumento válido em relação aos bancos de dados do lado do cliente. Imagine algum aplicativo simples para desktop (como, por exemplo, um simples jogo ou brinquedo) que precisa armazenar algumas dezenas de configurações e parâmetros. Parece muito exagerado fazer uma pessoa instalar o MySQL apenas para executar seu aplicativo.

Com o desenvolvimento da web, o servidor é naturalmente um back-end, onde ter um banco de dados é o mínimo. por exemplo. Os usuários não precisam se preocupar em instalar um banco de dados no final.

Os aplicativos da área de trabalho mantêm o estado enquanto estão em execução. Considerando que o desenvolvimento web normalmente não. Portanto, embora seja necessário armazenar uma configuração de usuário em um banco de dados entre as cargas de página, em um aplicativo de desktop, você apenas as mantém na memória. Isso reduz bastante a necessidade de tais tipos de armazenamento persistente. Quando você deseja armazenar preferências entre os usos, é possível salvá-las em um arquivo ou colocá-las em algum lugar como o registro do Windows.

Dito isto, os sistemas de banco de dados são bastante utilizados em aplicativos de desktop. Muito antes da Web, os aplicativos de desktop estavam conectados aos DBMS. Principalmente para aplicativos que não são baseados em documentos. Embora hoje em dia, com a melhor disponibilidade de motores leves, você esteja vendo as linhas borradas um pouco. Por exemplo, eu uso o SQLite db's como documentos em alguns dos meus aplicativos.

Uma coisa que você pode querer procurar são bancos de dados leves que não exigem um serviço de banco de dados em execução real. Por exemplo, na frente da Microsoft, existe o SQL Server Compact , que é gratuito, requer apenas um arquivo para o banco de dados e algumas DLLs adicionadas ao seu aplicativo e, da perspectiva do desenvolvedor, se comporta da mesma maneira que um SQL Server "real".

Estou certo de que existem opções semelhantes em outras plataformas.

Em aplicativos da Web, é importante armazenar qualquer estado persistente em um armazenamento centralizado. Como o aplicativo Web geralmente é o primeiro gargalo, é importante poder distribuí-lo sem ter que questionar qual cópia possui os dados (o princípio 'Shared Nothing'). Não apenas um banco de dados, mas também os memcachedsistemas de filas pelo mesmo motivo.

Os aplicativos de desktop não têm a mesma meta de escalabilidade. Normalmente, a maioria dos dados é armazenada localmente em cada estação de trabalho. O compartilhamento de dados é um problema diferente na maioria dos casos. Isso elimina um grande motivo para usar um banco de dados.

Os aplicativos da GUI também podem ter documentos complexos que podem ser tratados como uma rede complexa de objetos na memória. Normalizar a estrutura em um esquema de banco de dados relacional pode adicionar complexidade significativa ao problema; às vezes é mais fácil serializar tudo em um único bytestream. Muitas estruturas de POO incluem algumas facilidades apenas para isso.

Ainda assim, tornar os documentos armazenados legíveis com ferramentas fora do aplicativo principal é uma grande vantagem em muitos casos, portanto, o uso de formatos legíveis por humanos (XML, JSON, YAML, etc.) ou um arquivo zip que reúne várias partes mais simples mais comum.

Do mesmo modo, o uso de uma biblioteca de banco de dados incorporável (BDB, Tokyo Cabinet, SQLite, servidor MS-SQL * Compact, etc.) é outra ótima abordagem.

Os bancos de dados podem ser um exagero, mas geralmente não precisam ser. Programas muito simples simplesmente não precisam deles. Se o seu documento puder carregar na memória em uma quantidade trivial de tempo e permanecer lá sem problemas, você realmente não precisa de um para muitos programas.

Por exemplo, 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;
}

Bem, isso é simplista demais, mas obviamente isso é demais. Não há nenhum ponto real em ter esse nível de gerenciamento de dados para "Hello World"

Normalmente, a regra geral é a utilização de um banco de dados se você tiver muitos conjuntos de dados, especialmente se eles forem exclusivamente diferentes OU o uso de um banco de dados se a quantidade de dados for bastante grande. Os bancos de dados em geral estão associados a algumas despesas gerais, mas existem muitos que realmente não têm muito. Bancos de dados pequenos, leves e na memória, por exemplo, às vezes são úteis para pequenos projetos com processamento pesado, agendamento ou muitas alterações dinâmicas nos dados.

Existem diferentes estilos de codificação, muitas vezes não há nada errado com um banco de dados, mas a maioria de nós simplesmente não vai 'tão longe' para tarefas básicas. Outras vezes, o banco de dados correto oferece benefícios de desempenho. Tente entender especialmente as diferenças de onde os dados estarão, quanto tempo estarão lá e o que os modificará durante sua vida útil.

Usar um banco de dados é sempre a coisa certa e, com as implementações do SQLite para praticamente todas as linguagens existentes, não usar uma é apenas uma má tomada de decisão de design. A única razão para não usar uma é se você está fazendo programação incorporada ou algum outro tipo de programação que não seja de aplicativo. Consultar dados e configurações com uma linguagem declarativa como SQL é muito mais natural do que atravessar arquivos simples ou outros objetos na memória com sintaxe imperativa. Além disso, ele separa claramente as operações de dados de outro código de aplicativo que, a longo prazo, torna o código mais modular e sustentável.