sqllite ou firbird?

O que sugerem? Porque?

Haroldo,

Qual a necessidade?

A necessidade é que quero usar um sistema com um banco embarcadeiro ou embarcado (não requer instalação ou execução de serviço em segundo plano), e pelos estudo que fiz na net, não consegui achar qual é o melhor, mais rápido e seguro.

Entendi. Bom, até onde eu vi funcionando o Firebird me pareceu melhor e mais seguro que o Sqlite.

Melhor como?

Qual o melhor cliente grátis para manutenção?

O firebird precisa do Firebird instalado, ou estou errado?
Já o sqlite não precisa de nada correto?

Não tenho nada pra falar dos 2 apenas vi que queria um banco que não precisasse instalar nada.

Eu vi algo sobre firebird embarcado, mas não tenho experiência com isso.

Por isso a dúvida de qual dos dois usar: SqlLite ou FireBird.

Achei estes 3 links com comparativos acho que seria interessante olhar pois tem características de cada SGBD listadas e dependendo do recurso que você precise pode ajudar na sua decisão caso um tenha e o outro não.

http://db-engines.com/en/system/Firebird%3BSQLite

http://database-management-systems.findthebest.com/compare/13-53/Firebird-vs-SQLite

http://www2.sqlite.org/cvstrac/wiki?p=SqliteVersusFirebird

Para sistemas embarcados eu acho o sqlite mais leve e não precisa de nada instalado.
Sobre segurança… Sinceramente…

[]s

Haroldo, eu uso o Firebird nas minhas aplicações desktop, já usei uma vez embarcado funcionou direitinho, é bem simples, tem arquivo ZIP com todas as DLLs necessárias ai pela NET, veja o link tem uma explicação: http://relatosnoturno.blogspot.com.br/2010/09/firebird-embedded.html

Abraço.

Analisei esses comparativos ontem, mas confesso que não ajudaram.

Não precisa instalar o firebird.
Somente a biblioteca cliente.
dll no windows ou .so no Linux

Para usar o firebird embarcado não precisa instalar nada, só as DLLs mesmo.
http://www.firebirdsql.org/en/firebird-2-5-2-upd1/
Veja neste link tem os Zips para 32 e 64 bits.

Alguém que defenda o SQLite?

O scriptcase usa o SQLIte.
Eu acho rápido e simples.

Em defesa do SQLite…

Há alguns meses algum usuário mostrou, aqui no fórum, um Sistema para Hotéis, que se não estou enganado foi feito em cima do SQLite.
Se ele ler esse post, de repente, pode falar mais sobre o porquê escolheu o SQLite.

Eu estou usando o SqLite em uma aplicação nova que estou desenvolvendo para gerenciamento de obras onde irei disponibilizar o sistema para instalação em plataformas móveis tais como celulares e tablets rodando uma versão de um servidor web enxuta como o ligthhttp. Pelos testes que venho fazendo acho o SqLite muito bom levando em conta que é um arquivo auto gerenciado e tomei a iniciativa de usá-lo também devido a não conhecer nenhuma outra alternativa que me permita fazer isso. Ou seja com SqLite tenho meu sistema pronto para várias plataformas sem me preocupar com o que foi mencionado acima, drivers, dlls ou algo assim é um recuros nativo do PHP a alguns anos. Sem falar que no caso do Sqlite a segurança esta mais ligada ao sistema hospedeiro que ao próprio banco por se tratar de arquivo simples, e em termos de perfomance, bem os celulares podem responder por sí… em desktop pra melhorar o desempenho é só trabalhar com HD´s SSD que claro faria qualquer SGBD voar.

Pelos estudos de comparação o SQLite só ganha do Firebird se executarmos:

PRAGMA synchronous = OFF

O que causa um risco quanto a queda de energia, pois o sistema operacional que se encarrega de atualizar o disco.

O Sqlite tem vantagens de performance também quanto a quantidades de interações / segundo, quanto mais mis rápido.

http://ea.tl/embeddeddb.shtml

Minha intenção é performance, dou mais prioridade do que para segurança nesse caso.

Um link interessante a se olhar:

http://sqlite.org/whentouse.html

Mudei de opinião com relação ao sqlite. Só conhecia por conta da instalação padrão do sc, onde usando com mysql o sc fica bem mais rápido, mas, para aplicações embarcadas e simplistas o sqlite parece ser uma mão na roda.

Muito bom este comparativo, realmente não conhecia este recurso que aumenta muito a performance.