Planilhas – Excel, Google Sheets ou uma planilha com qualquer outro nome – são ferramentas muito legais e poderosas. Mas então, os bancos de dados também. Quando você deve ficar com uma planilha? Quando você deve migrar para um banco de dados?
Esta é a continuação do meu artigo anterior “Planilhas vs. Bancos de dados:é hora de mudar?” onde discutimos as desvantagens mais comuns de usar planilhas para organizar muitos dados. Neste artigo, descobriremos como um banco de dados resolve esses problemas.
Usando um banco de dados para organizar dados
O meu lema é “utilize a tecnologia adequada às suas necessidades”. Se você pode administrar seu negócio por meio de planilhas, ótimo! Se você precisa de um banco de dados simples, o MS Access não é uma má opção. Mas se esses produtos não funcionarem para você, você provavelmente precisará de um banco de dados personalizado e um aplicativo da web. O banco de dados armazenará seus dados; o aplicativo da web será uma maneira amigável de interagir com o banco de dados e se comunicar com a camada de dados.
Nosso negócio de serviços fictício não era muito complicado, então pudemos alimentá-lo usando um modelo de dados bastante simples. Se você observar a imagem abaixo, verá que tudo o que precisamos está armazenado em apenas cinco tabelas:
client_type , client , service , replacement e has_service . 
Uma regra fundamental do design de banco de dados é manter os dados relacionados do mundo real em um só lugar . Nesse caso, manteremos todos os nossos client dados na tabela cliente. Dessa forma, evitaremos armazenar os mesmos dados em vários locais (o tipo ruim de redundância mencionado anteriormente). Se alterarmos algo relacionado a um cliente, faremos apenas uma vez, nesta tabela. Isso melhorará muito a qualidade dos dados e será bom para o desempenho.
A próxima tabela que contém dados do mundo real é o service tabela. Novamente, podemos armazenar todos os detalhes relacionados aos nossos serviços aqui e podemos fazer alterações nos dados com bastante eficiência.
O client tabela e o service table são entidades do mundo real que poderiam existir sem a outra. No entanto, criar um banco de dados com entidades não relacionadas não faz muito sentido – é como ter clientes sem produtos ou serviços sem compradores. Portanto, relacionaremos essas duas tabelas usando o has_service tabela. Para armazenar informações sobre quais clientes têm qual serviço, usaremos chaves estrangeiras que atuam como referências a esse cliente e serviço. Essas chaves estrangeiras apontam para registros nas tabelas de serviço e cliente. Também podemos manter nesta tabela qualquer informação adicional relacionada a cada relacionamento de atendimento ao cliente.
O client_type table é usado como um dicionário que armazena todo tipo possível de cliente. É melhor manter diferentes segmentações em tabelas de dicionário separadas (por exemplo, se tivéssemos tipos de clientes e tipos de funções de funcionários, nós os armazenaríamos em tabelas diferentes). No entanto, precisamos apenas de uma tabela porque este é um modelo simples.
A última tabela em nosso modelo é a replacement tabela. Vamos usá-lo para relacionar dois serviços:um serviço que queremos substituir e o serviço de substituição. Isso nos dá a flexibilidade de oferecer aos clientes substituições para serviços existentes (como mudar de um plano de chamadas móveis para outro).
Vantagens do banco de dados
Bancos de dados são mais complicados de configurar do que planilhas, mas isso realmente lhes dá algumas vantagens significativas em termos de integridade e segurança de dados:
Chaves e restrições
Os bancos de dados têm regras e controles internos que, se usados corretamente, evitarão a maioria dos problemas de qualidade e desempenho dos dados. Chaves primárias (colunas que identificam exclusivamente cada registro em uma tabela) e chaves estrangeiras (colunas que se referem a um registro em outra tabela) são críticas para a segurança dos dados, mas definir chaves alternativas ou ÚNICAS (que contêm dados exclusivos para cada registro em uma tabela ) também é muito útil.
Em bancos de dados relacionais, as chaves relacionam dados de diferentes tabelas. A chave primária da tabela é sempre ÚNICA, enquanto uma chave estrangeira referencia a chave primária de alguma outra tabela. Essa referência relaciona dados dessas duas tabelas (por exemplo, as chaves estrangeiras no arquivo
has_service tabela relaciona os dados dos clientes com os serviços que eles possuem). Ele também nos avisará se estivermos prestes a excluir uma chave primária referenciada em alguma outra tabela. Isso nos impedirá de excluir registros que ainda são necessários (como referências) em outra tabela. As restrições definem o tipo de dados que podem ser inseridos em um campo. Podemos especificar que os dados devem ter valor (NOT NULL), definir um formato para números de telefone, conter apenas letras e assim por diante. Isso significa que podemos evitar problemas de dados de pessoas que inserem o tipo errado de dados em um campo.
Segurança e permissões
Outro recurso de banco de dados muito importante é controlar o acesso aos seus dados . Isso lhe dá a capacidade de definir não apenas quem pode acessar seu banco de dados, mas também controlar o que eles podem ver ou modificar. Esta é uma grande parte da segurança de dados. Por exemplo, você pode definir uma função de usuário que permita que um funcionário altere os detalhes do cliente, mas não os detalhes do serviço. Você também pode definir regras sobre quais funcionários podem alterar ou excluir dados. É uma boa prática padrão garantir que as pessoas tenham acesso apenas aos dados de que precisam para realizar seus trabalhos.
Claro que poderíamos tentar recriar essas funcionalidades em planilhas (pelo menos de alguma forma), mas isso com certeza seria “reinventar a roda”.
Não poderíamos simplesmente usar uma planilha?
Claro que poderíamos. Poderíamos criar planilhas que seguem o mesmo padrão usado no modelo de dados. Isso resolveria muitos problemas de dados, mas…
Replicar o modelo de dados em planilhas definitivamente não é a opção ideal. Perderíamos todas as vantagens que o sistema de banco de dados nos oferece, todas as regras e restrições que mantêm os dados “saudáveis”, todas as coisas que evitam exclusões acidentais e outros erros. Perderíamos a otimização e, se o conjunto de dados fosse grande o suficiente, o desempenho seria prejudicado.
Mesmo se resolvermos isso, que tal compartilhar dados, por exemplo, ter vários usuários usando a mesma planilha ao mesmo tempo? Que problemas de integridade e desempenho de dados isso causaria? Isso seria o oposto de manter as coisas simples.
Portanto, se você acha que as planilhas não podem atender às suas necessidades de negócios, provavelmente já está indo em direção a um banco de dados. Se você estiver preso a dados armazenados em planilhas e quiser migrar para um banco de dados, deverá:
- Crie um modelo de banco de dados que armazene seus dados de forma otimizada.
- Crie um aplicativo com o banco de dados em segundo plano.
- Limpe seus dados, transforme-os (se necessário) e importe-os para o banco de dados.
- Continue trabalhando apenas com o banco de dados.
Qual você deve escolher – planilha ou banco de dados?
No artigo de hoje, aprendemos como um banco de dados resolve problemas com o uso de planilhas para organizar muitos dados. Meu conselho é sempre escolha a solução mais simples para o seu problema . Se as planilhas funcionarem corretamente, use-as. Mas se você é uma empresa orientada a dados, deve começar a usar um banco de dados o mais rápido possível. Quanto mais você esperar para limpar e migrar seus dados, mais doloroso será o processo.
