Exemplo de banco de dados de arquivo simples

Question

Gostaria de ver alguns exemplos de bancos de dados simples de arquivos simples e como eles são acessados ​​por meio de uma camada de dados.Já escrevi e li um arquivo simples antes, mas nunca criei uma camada de dados que acessasse os dados de um aplicativo usando arquivos de texto.

Se possível, seria bom ver um tutorial que tivesse uma camada de dados que utilizasse um banco de dados de arquivo simples simples e personalizado.Um exemplo que salva objetos de negócios personalizados em XML e depois os carrega seria bom porque XML é muito popular e fácil de trabalhar.

Eu também ficaria grato por quaisquer links para sites que discutam as melhores práticas em relação ao design de bancos de dados de arquivos simples, etc.

Meu objetivo é ter uma solução para armazenar dados simples na máquina de um usuário e fazer com que ele não precise de nenhum software especial instalado (como SQL Server, etc.) para buscar os dados de onde estão armazenados.

Eu sei que esta é uma pergunta muito geral, mas qualquer conselho que possa me indicar a direção certa é bem-vindo.

Answer 1

Você pode ter confundido um pouco suas definições, o que é compreensível devido ao grande número de tecnologias semelhantes existentes hoje.

XML não é um formato de arquivo simples (ou banco de dados de arquivo simples), mas ao ler seu objetivo, parece que o que você realmente deseja é um banco de dados relacional independente, em vez de um arquivo simples real.

Como outros, recomendo fortemente o SQLite para essa finalidade.Existem ligações para várias plataformas, o .NET tem Sistema.Data.SQLite que, em um arquivo, é o provedor e o mecanismo do banco de dados.

Os dois grandes benefícios de usar SQLite são que o banco de dados real é completamente contido em um único arquivo controlado por seu aplicativo e suporta comandos SQL DDL e DML padrão (ou seja, SELECT, INSERT, UPDATE, DELETE, CREATE DATABASE/TABLE etc. ).

Para um aplicativo de usuário único, o SQLite é uma excelente (uma das melhores) maneiras de armazenar dados e configurações do aplicativo.Ultimamente aí houve discussão que pode até suportar aplicativos multiusuários de menor escala.

No entanto, Oracle, MySQL, SQL Server etc. ainda são definitivamente preferidos para aplicativos multiusuário (mesmo aplicativos de pequena escala) se você tiver a capacidade de acessar/utilizar um servidor de banco de dados.

Além disso, não esqueça que a escolha do banco de dados não é mutuamente exclusiva.

Você pode ter um aplicativo multiusuário com uma UI rich client instalada nos computadores de muitos usuários.O banco de dados central aqui deveria ser realmente um banco de dados multiusuário, como o MySQL.Mas dentro da UI do rich client, o SQLIte é ideal para armazenar as configurações de cada usuário ou talvez para fornecer suporte off-line quando o banco de dados não puder ser acessado.

Answer 2

grande é um que usei no passado.Ele salva como JSON em flatfiles e você pode encontrá-lo no Github

Answer 3

Formatos de texto como CSV, INI, XML podem ser usados ​​para armazenar dados estruturados, mas o IMO não é flexível ou eficiente para ser usado como banco de dados.

Eu recomendo SQLite como uma excelente alternativa.É um mecanismo de banco de dados muito poderoso, leve e independente.

Answer 4

Você pode ter seu bolo e comê-lo também:

SQLite é um banco de dados SQL que consiste em um único arquivo e não requer instalação, possui vínculos para diversas linguagens e roda em diversas plataformas.

No caso mencionado, não há necessidade de escrever sua própria camada de dados sobre arquivos simples.Na verdade, a menos que você queira um exercício de aprendizagem, desaconselho fazê-lo.

Answer 5

Existem vários bancos de dados incorporados disponíveis com os quais seu usuário não precisará se preocupar.

SQLLite é comum, popular, multiplataforma, etc.Depende da sua linguagem de implementação.Se você usa Java, existem vários, Derby por exemplo..NET não é meu ballywick, mas imagino que haja algo lá.No mínimo, o MS possui um mecanismo SQL incorporável e de desktop de uso livre que você pode usar.

Escrever o seu próprio pode ser um exercício interessante, mas essa roda já foi concluída e é simplesmente mais fácil e eficiente usar um banco de dados existente do que começar do zero.Seus usuários não serão afetados por isso, portanto, se esse for o fator principal, não há razão para não usar um produto/projeto disponível.

Answer 6

Existe o DBD::CSV módulo em Perl que pode carregar arquivos csv e consultá-los com instruções SQL.Mas para o seu objetivo, acho que seria melhor investigar SQLite que é um banco de dados relacional adequado que funciona sem servidor.

Answer 7

Em vez de reinventar os bancos de dados, por que não agrupar seu aplicativo com um mecanismo de banco de dados simples?Os bancos de dados vêm em vários tamanhos, nem todos são enormes :-)

Se você quiser reinventar a roda, observar o código-fonte de mecanismos simples de banco de dados de código aberto deve indicar a direção certa.

Answer 8

Concordo com os muitos comentários que sugerem que é melhor usar um mecanismo de banco de dados existente.No entanto, como uma tentativa de realmente responder à pergunta:

• Um formato de banco de dados de arquivo simples extremamente comum é o Xbase (arquivos normalmente com extensões .dbf).Você pode pesquisar no Google por "xbase" e "dbf" e encontrar muitas informações e qualquer número de drivers.Você deverá ser capaz de extrair algumas dicas e sugestões se estiver realmente interessado.
• Se quiser brincar com um que seja muito provável em seu sistema, você pode usar o ODBC "Microsoft Text Driver".Se você tiver algum material de acesso a dados da Microsoft em sua máquina, provavelmente possui esse driver.Não tenho certeza, mas provavelmente está instalado com o MDAC.Esse driver irá ler e gravar arquivos de texto separados por vírgula (entre outros formatos).