SQLite Alternativas para C ++ [fechado]

Question

Estou desenvolvendo um aplicativo que precisa para armazenar dados com muitos escreve e lê como necessitando de procura rápida de dados (a necessidade de índices de algum tipo), e também ser capaz de serialize e salvar os dados.

Atualmente estou pensando em usar o SQLite, que começa o trabalho feito, mas estou aberto para alternativas. sintaxe do SQLite realmente não se encaixa elegantemente em código C ++ (por exemplo, sou forçado a acessar os resultados por números de índice de coluna em vez de nomes de colunas, etc).

Answer 1

Fique com SQLite, mas encontrar uma biblioteca boa C ++ para isso.

Este StackOverflow pergunta deve ajudá-lo. ..

Answer 2

Eu diria que a dependência adicionados em uma biblioteca wrapper não vale a pena o custo de ter que lidar com os custos do que a dependência extra. Você não quer ser preso depuração estes libs de mensagens publicitárias quando a documentação para eles pode ser escassa. SQLLite é obrigado a ser mais estável e tem uma melhor documentação e, portanto, uma dependência mais confiável.

Eu quer lidar com SqlLite ou envolva-se, de alguma forma inteligente baseado em sua aplicação final.

Answer 3

Soa como se um banco de dados é a única opção real para você. Se você escolheu SQLite ou MySQL ou PostgreSQL não importa realmente no ponto de índice de coluna, no entanto.

Talvez o que você realmente quer é uma melhor abstração de banco de dados. Você pode querer tentar Poco, ele tem um grande: http://pocoproject.org/

Answer 4

Berkeley DB aka sleepycat. Se você pesquisa nos arquivos, há um artigo de Mike Olsen, que fala sobre as principais desvantagens de SQL em qualquer projeto. Há um outro artigo de acompanhamento no último ano, que sugere que o SQL está em sua maneira de sair porque as camadas ORM estão ficando muito melhor.

Answer 5

Se você perguntar-me ficar com SQLite e "fazer sua própria" - a embalagem é muito simples eu fiz vários envolvimentos sobre SQLite mim. Por quê? Devido a sua API é muito mais amigável do que qualquer outra base de dados qualquer coisa relacionada e você não precisa gastar muito esforço. Com uma biblioteca de wrapper você só vai adicionar mais unlnowns e mais importante a maioria das embalagens não são especialmente dedicada a servir bancos de dados incorporados. Estou sempre repetindo que, com banco de dados incorporado o caminho certo é muito diferente da abordagem ideal para um servidor de banco de dados ...

Answer 6

Se a sintaxe SQL não é importante para você, eu recomendo MetaKit - É um pouco diferente abordagem mas muito poderoso e eu, pessoalmente, conheço mais do que alguns projetos comerciais que usam com sucesso, mesmo em sistemas embarcados.

Este Tutoria l é bastante útil para começar.

Answer 7

Poderia eu sugiro que você dê uma lista dos invólucro APIs listada no site Sqlite? Há muito lá para muitas línguas, incluindo C ++. Sqlite Além disso, parece particularmente bom. POCO, que 'usuallyuseless' mencionado, parece ser bom também.

Answer 8

Eu concordo, é falso dizer SQLite é incompatível tanto com C ++ ou nome da coluna indexação Há uma abundância de wrappers C ++ SQLite que incentivar colunas que acessam pelo nome. SQLite ++ é apenas um de muitos.

Answer 9

Em vez de um derivado sql, você pode pensar em usar uma biblioteca índice invertido IR como Lucene (ou um dos muitos clones lá fora). Eu sei Lucene é Java, mas você poderia escrever uma biblioteca C ++ gerenciado para interoperabilidade com Lecene.Net.

No que diz respeito a velocidade, eu estou muito feliz com o desempenho do Lucene para a sua leitura. Não é tão otimizado para suas gravações, mas sua boa ainda bastante, contanto que seu não tentando construir um índice de milhões de "documentos".

Answer 10

Se você não está trabalhando no Windows, você pode olhar para Tokyo Cabinet. Parece ser muito bom. Eu estou esperando para a porta Win32, por isso não posso dizer muito sobre ele que não seja a aparência de desempenho a ser impressionante.

http: // anyall.org/blog/2009/04/performance-comparison-keyvalue-stores-for-language-model-counts/

Este não é um derivado SQL. É uma b-tree / hash de loja em linha reta baseado. Isto é muito bem-vindo, na minha opinião. A biblioteca só competitivo que eu estou ciente de Berkeley DB, que tem menos de licenciamento desejável.