Ranking do BDs em Março de 2015

O MongoDB possui uma forma totalmente diferente de trabalhar... Também me surpreendi, justamente por ser um banco criado recentemente.
Eu não cheguei a utilizar ele, apenas li alguns artigos a respeito, mas eu me questiono até que ponto pode ser boa a forma que ele armazena os dados.

Estou realmente surpreso pelo ranking.

Oracle e SQL Server, eu esperava isso ou ao contrario.

MySQL sendo surpresa pra mim!!!

Me surpreendi com o MySQL também...
O Oracle não me espanta, pois eu conheço e realmente é um banco muito bom.
Mas o MySQL agora é de propriedade da Oracle, acredito que isso tenha algo a ver pois ele deve estar bem melhor...

Pode até ser que tenha considerado as melhorias do MySQL se comparando com versões anteriores, mas estou apenas chutando.
Tambem com Oracle não me surpreende, mas realmente o MySQL foi uma surpresa.

Estou impressionado com a posição do MongoDB. Mal saiu ja ta em quarto

Oracle no topo sempre...

Já utilizei o MongoDB, ele não é um banco relacional, porém me sentir muito a vontade com ele!
Para efetuar as consultas mesmo é coisa de cinema rsrs
Não sei até onde ele pode ser útil, mas para algo simples funciona perfeitamente!

Tambem tem isso, um banco novo ocupando otimas posições.



Pois é, me respondam quem puder, o Oracle está topo por ser um SGBD por ser realmente o melhor banco para empresas gigantes ou é mais popular mesmo?

O Oracle é considerado o melhor em recursos de segurança e performance.

Na epoca que fiz um curso de SQL Server, falavam bastante do Oracle, por realmente suportar bancos gigantescos! muitas operações...etc.

Como estão dizendo, também estou surpresa pelas colocações dos bancos. MySQL, pelo visto melhoraram bastante!!!

Tambem, um banco novissimo no mercado, pra falar a verdade só conheço de "vista".

Eu fico imaginando se ele manteria boa performance no caso do banco possuir uma grande carga de dados.
Como você mencionou, Thiago, para soluções simples ele funciona perfeitamente, mas e para soluções complexas?
Alguém de algum caso de uso dele em soluções complexas?

É bom saber quais empresas utilizam ou passaram a utilizar o MongoDB para termos uma base.

Já chegou a conhecer Marisiana?

Não cheguei a conhecer... Apenas li alguns artigos e outros materiais teóricos para entender o que é...

Eu tentei conhecer o MariaDB mas não tive muito sucesso, hehehe

Antes de chegar ao meu conhecimento bancos NoSQL eu pensava que quem poderia ocupar lugar no mercado seria os bancos orientados a objeto, mas me falaram que eram bastante lentos, isso ainda se confirma?

Realmente não sei qual a situação atual desses bancos, é notorio que os NoSQL ultrapassou.

Acho que realmente não vingou comercialmente.

Tambem acho que foi isso.

Alguém sabe dizer como está a utilização dos bancos NoSQL no mercado de trabalho?

Esse foi o projeto que trabalhei com MongoDB

Projeto usando MongoDB

Utilizamos uma integração entre linguagens (Delphi e Ruby) e Bancos (Firebird e MongoDB). Deu tudo certo! :)

O MongoDB é para aplicações web com acesso a banco de dados em grande escala(muitos acessos)?

Aparentemente, a aplicação parece ser normal...!
Na sua opinião Thiago, para desenvolver uma aplicação assim, você acha que é melhor de trabalhar com uma estrutura não-relacional ou com uma estrutura relacional?

Marisiana, pergunta difícil de responder! rsrs
Afinal de contas essa foi a única vez que utilizei um banco não relacional!
Uma coisa que achei fantástica foram as consultas e inserts, muito rápida e bem simples.
Exemplo:

Para varia a resposta padrão depende do cenário.

Estou desenvolvendo uma aplicação financeira em que seria ótimo poder utilizar um banco de dados não relacional, pois iria facilitar absurdamente a implementação e a performance.
Por se tratar de um sistema de simulações financeiras centenas de indicadores e formulas matemáticas complexas um banco orientado a objetos seria de grande ajuda.
Pois o que importa são os indicadores calculados pela simulação, os dados da simulação seriam como rascunhos, então não seria necessários tê-los para consultas relacionais.
Só não utilizei um bd NoSql pois a diretriz tecnológica da empresa dona do projeto é rígida e define como baco de dados Oracle ou SQL Server.

Para contornar acabei serializando os dados e gravando em bd Oracle o que para a maioria dos DB´s configuraria um heresia passível de ser condenado a fogueira. Só que no cenário do projeto é a melhor solução. Inclusive facilitando incrivelmente a codificação da aplicação.

O fato da maioria das pessoas não usarem e desconhecerem os db´s NoSql e orientados a objeto, não quer dizer que fracassaram ou não vingaram comercialmente.
Normalmente se opta por usar um bd relaciona por comodidade ou por achar que uma nova tecnologia demandaria uma curva de aprendizado enorme e nem sempre é verdade.
E claro a maioria da área de dados torce o nariz quando se fala em bds não relacionais.

Já que eu li sobre banco de dados orientado a objeto, como está atualmente Jothaz?

Jothaz, nesse caso de uso que descrevestes, não seria viável utilizar um Data Warehouse?

Olha não sou especialista, mas segue o que sei sobre o assunto e infelizmente não da para ser sucinto devido a complexidade do assunto.

Antes de mais nada devemos esclarecer os conceitos envolvidos, pois existe uma grande confusão entre NoSql e BD´s Orientado a Objetos.

Apesar dos BD´s relacionar se tornarem padrão, conseguir uma maturidade e robustez inegável o seu uso apresenta alguns problemas:
--Dados na ordem de dezenas ou centenas de TB - abordagem de cluster é cara
--Poder de crescimento elástico horizontal - controle de transação ACID torna inviável com a elasticidade
--Fácil distribuição dos dados e/ou processamento - SGBD paralelos são caros
--Tipos de dados variados, complexos e/ou semiestruturados - modelo de dados objeto-relacional não resolve todos os requisitos

Neste contexto surgiram os banco de dados que fogem ao paradigma do Objeto Relacional.

NoSql é uma tecnologia que alguns BD´s Orientado a Objeto usam sem a abordagem relacional, não necessariamente sendo orientados a objetos. O NoSQL (Not Only SQL) define que o BD em questão pode, ou não, responder a sentenças SQL. Normalmente estes bancos de dados respondem sentenças em formato próprio ou em outros formatos conhecidos (como o json, por exemplo).

Segundo este artigo da [url:descricao=Wikipédia ]http://en.wikipedia.org/wiki/NoSQL[/url] os BD´s podem ser separados de acordo como cada um armazena a informação:
Como Coluna
--Accumulo, Cassandra, HBase
Como Documento
Clusterpoint, Couchbase, MarkLogic, MongoDB
Como Chave-valor
--Dynamo, FoundationDB, MemcacheDB, Redis, Riak, FairCom c-treeACE
Como Grafo
--Allegro, Neo4J, OrientDB, Virtuoso

Um banco de dados orientado a objeto normalmente guarda um objeto de uma linguagem conhecida, como o Zope Object Database que guarda objetos python, sem necessariamente haver uma transliteração de dados.

Um banco de dados orientado a documento, que as vezes é confundido com um banco de dados orientado a objeto, armazena documentos em algum formato específico. Por exemplo, o MongoDB armazena documentos em formato bson ("Binary JSON", ou "JSON Binário"). Assim para um documento se transformar num objeto, teria que ter uma tradução de dados do documento para o objeto da linguagem em questão.

Quais seriam as vantagens do uso de BD orientado a objetos:
--Consegue-se modelar objetos mais próximo ao mundo real;
--O Progamador pode manter a consistência do ambiente de desenvolvimento ao integrar um banco de dados a um paradigma de linguagem de programação e depois apresentar em um único modelo de projeto;
--Rapides de inserção;
--Utiliza pouco recurso computacional;
--Tem fácil aprendizado (por incrível que pareça depois do choque inicia fica fácil);
--Acesso direto ao Banco de Dados sem utilizar o mapeamento objeto relacional.

As principais aplicações:
--Projetos de engenharia e manufatura, experimentos científicos, industria bélica, telecomunicações, sistemas de informações geográficas e multimídia.

Se não me engano algumas empresas que utilizam BD Orientado a Objetos:
--Twitter, Ricoh, BMW e Boing.

Realmente suas informações eu desconhecia, li a um tempo atras sobre esses bancos, e realmente para mim é uma surpresa ler que ele é rapido, pois na epoca que estava atras do assunto me falaram que ele não substituia os banco de dados tradicionais por ser lento.

Neste cenário não!

No início fiz uma abordagem relacional só que quando começamos a implementar e criar o MockUp e provas de conceito chegamos a conclusão que seria impraticável utilizar o modelo relacional somente.
A questão não é o BD suportar a quantidade de dados, isto seria fichinha para o Oracle. O problema seria na implementação, pois o código ficaria complexo e pesaria em demasia o servidor. Com a serializaçã utilizando o JSon podemos utilizar o AngularJS e deixar todo o processamento do cálculos (são centenas) do lado do cliente. Assim facilitamos a implementação e liberamos o server de aplicação e não entulhamos o servidor de BD com um monte de dados sem necessidade.

No caso a aplicação permite fazer várias simulações utilizando-se de vários indicadores (impostos, depreciação, densidade demográfica, amortização, despesas, receitas e por ai vai) de onde se chega a alguns valores para avaliação. O dados usados nas simulações não são tão importantes (seriam como os rascunhos em provas) então podemos guardá-los serializados e exibí-los via aplicação quando necessários. Agora o valores gerados são gravados em tabelas devidamente normalizadas.

Inicialmente até eu achei a abordagem radical demais, mas depois de algumas provas de conceitos até a área de dados concordou que era a melhor solução. E convencer DBA a não usar a abordagem relacional é como um parto de hiena.

Entendi... Mas o Data Warehouse utiliza o modelo multidimensional de dados, não é igual ao modelo relacional.
Ele mantém o relacionamento entre os dados, mas possibilita analisar uma mesma informação em diferentes ângulos e níveis de detalhamento.

Jothaz???

Thiago vc conhece algum servico de host q usa o MongoDB?
To fazendo um sistema de marketing com Php, Angular e MongoDB

Era o meso argumento que era usado contra os BD´s Relacionais em relação aso BD´s Hierárquicos.

Pode ser que no inicio da implementação dos BD´s Orientado a Objetos eram lentos, mas com os avanços, principalmente de hardware a diferença só vai diminuindo.

E as pessoas falam muita besteira sem ter conhecimento é o que mais acontece principalmente referente a TI.
Opinião é sagrada mas deve ser embasada em argumentos lógicos e válidas senão fede. kkkk

Com relação a não se ter hype sobre algumas tecnologias não que dizer que elas não existam ou são usadas. Por exemplo talvez você nunca tenha ouvido falar sobre Pick System, também conhecido como D3 ou Pick AP. É tecnologia mais antiga que minha vó, eu trabalhei com ele a uns 30 anos atrás e por incrível que pareça ainda é utilizado e pagam uns 6.000,00 para os profissionais que a utilizam. Cobol mesmo é amplamente utilizado e paga o mesmo e normalmente ninguém fala sobre isto. Enquanto um profissional Delphi sênior aqui na minha região e remunerado com 2.000,00.

Acho que não estou conseguindo ser claro.

O problema não é extrair os dados o problema é fazer as simulações e cálculos online. Vou tentar exemplificar. Você já viu nas lojas quando o vendedor usa um sistema para dar vários descontos até chegar a um preço para venda. A aplicação que estou desenvolvendo é parecida. No caso do exemplo da venda o vendedor tem uma quantidade, um preço de custo e o preço de venda. Ele aplica vários indicies de até chegar a um preço que ele possa fazer. No final o que importa é o valor cobrado.

A aplicação que estou desenvolvendo é parecida, só que pode-se salvar várias versões de cada simulação. A diferença é que são centenas de insumos para chegar-se aos indicadores. Pode-se vairar um período de tempo, o valor do lucro, o valor do prejuízo, o valor dos impostos (ou calcular com todos ou somete alguns), o valor da depreciação, o valor de amortização, o valor de investimentos, o valor do índice de inflação, o valor das despesas, o valor da moeda (reais, dólar, euros e etc) e por ai vai. Tudo isto é feito online e eu tenho de persistir todos estes dados. Só que os dados são como um memória de calculo não são usados para nada o que interessa são os indicadores gerados que serão usados por várias áreas: comercial, planejamento, engenharia e etc. Se alguém precisar verificar como se chegou ao indicadores (98% das vez não se preocupam com isto) ou mesmo auditar os valores estão salvo. Então é só buscá-los deserializá-los e exibir.

Se futuramente esta memória de calculo passar a ser pertinente é só criar um webservice ou app que rode como serviço recupere os dados e os grave em tabela relacionais ou mesmo para DW.

Claro que eu poderia salvar tudo em tabelas relacionais só que fica muito pesado e a implementação fica complicada de forma desnecessária. Então ao gravar o objeto Json basta uma leitura e posso preencher meus objetos do AngularJS sem nenhum problema e de forma fluida. Se usasse as tabela relacionais o processo demoraria vários minutos ao usar o Json demora segundos e usa somente a memória do cliente e com tráfego na rede minimo.

E tem mais as versões novas do Chrome (acho que o IE também) tem uma ferramente que me permite gravar dados nos clientes, é tipo o SQLite imbutido, então se a coisa pesar basta gravar meu dados serializados nesta área do navegador e que me proporciona mais ganhos ainda. E só persisto no BD depois que o usuário definir que aquela simulação é pertinente.

Inicialmente eu também torcia o nariz para este tipo de abordagem só que depois que você compreende e vê o benefícios não tem como questionar o ganho e a flexibilidades são absurdos. Claro tudo depende do bom senso e uma parte grande do sistema é relaciona e segue a normalização. E para usar a abordagem proposta deve-ser criar um modelo de dados com muito mais atenção.

pessoal, alguem ja teve algum problema , ou ouviu falar com Firebird, tipo lentidão com algumas maquinas em rede ou geração de arquivos, banco muito grande algo assim ?

Deve ser propaganda enganosa, querendo tirar a atenção para esses bancos. Talvez não demore muito para haja uma competição mais acirrada com essas arquiteturas de bancos.

Esperar alguem que conheça bem o Firebird, eu, pelas minhas pesquisas em foruns nunca ouvi falar.

Entendi Jothaz! Obrigada pela explicação!

Sabe me dizer se o SQLite, esse é um banco NoSQL ?

O Oracle e SqlServer são os bancos mais utilizados no meio corporativo, o mysql é muito utilizado em pequenas aplicações e para estudo. Se a pesquisa toma como base parametros técnicos com segurança e escalabilidade por exemplo, o Oracle e SqlServer encabeçam a lista, mas ele se baseia em utilização, o Mysql ganha de lavada, pois é free, é fácil, é dinâmico e é o bicho.

Tambem acho Alex, os dois maiores são o SQL Server e Oracle, não necessariamente nessa ordem.

Tambem acho Alex, os dois maiores são o SQL Server e Oracle, não necessariamente nessa ordem.

Me metendo, eu acho que não Marisiana. [url]https://www.devmedia.com.br/sqlite-muito-prazer/7100[/url]

Alan, obrigada por responder!
Então, pelo que entendi os dados são armazenados em arquivos e não possuem FKs que fazem as ligações entre eles.
Isso não seria orientação a objetos?

Sinceramente não sei e não tenho certeza.

Eu tenho certeza disso, mas esses dois bancos proprietarios são os dois grandes do mercado.

O MySQL se destaca por ser muito utilizado em sites e aplicações web que não exigem um SGDB tão robusto para manter os dados.

Devemos levar em consideração essa informação tambem, sinceramente, só vejo cursos mostrando a integração de Java e PHP com MySQL, vejo como sendo popular alem de ser bastante utilizado na web, como disse.

E quem trabalha com o desenvolvimento de sites, prefere utilizar o MySQL.
Nesse caso, quais seriam as vantagens do MySQL em comparação aos demais bancos?

Informações técnicas eu não sei, mas acho que a facilidade em encontrar nas hospedagens mais simples.

Isso deve ter muito a ver Roniere...
Agora lembrei que um colega de profissão comentou alguma coisa sobre as hospedagens, sobre algumas facilidades e vantagens que há.
Só que não consigo lembrar qual foi o comentário que ele fez... =/

Facilidades tambem na questão $$$$.

Ah é.. Isso também deve influenciar!
Mas dai eu já me perguntei o porquê do uso do MySQL e não do PostgreSQL, sendo que ambos são free.
Então esses vantagens devem influenciar nisso também...

Sobre o postgre eu realmente não sei, talvez a manutenção dele seja mais complicada, estou apenas chutando, mas raramento vejo hospedagens oferecem de cara esse SGBD.

Oi Marisiana, desculpe-me por demorar a responder, mas ultimamente estou com meu tempo contado.

Talvez o link postado tenha esclarecido, mas vou tentar aclarar mais o tema.

O SqLite é um bando SQL relaciona como qualquer outro do mercado. Só que é muito mais simples de instalar e configurar. A grande vantagem é que ele pode ser usado criando o ".bd" e as tabela dentro do mesmo. Provavelmente você tem vários bancos no seu computado e nem percebe isto.

Existe softwares para gerenciar o banco de dados e é suado a linguagem (DML) de qualquer BD do mercado. Então ele seria igual ao MySQL, PostgreSQL, Oracle e MySQL. Em tese ele poderia ser usado em 90% dos sites que existem na web, mas qual seria as desvantagens de usá-lo?

Bom ele não impõe integridade referencial nativa, então você tem de controlar isto na mão ou via trigger e não é escalonável como os demais bd´s.

As vantagens seriam:
--Software livre/domínio público e Multiplataforma;
--Mecanismo de armazenamento seguro com transações ACID;
--Não necessita de instalação, configuração ou administração;
--Implementa a maioria do SQL92;
--O Banco de Dados é guardado em um único arquivo;
--Suporta bases de dados acima de 2 terabytes;
--Sem dependências externas.

Sei que vou receber vários "deslikes" e muito vão quer minha cabeça em uma estaca, mas como acho que o debate e desmistificação são a melhor solução para tudo, vou expor minhas considerações sobre o MySQL.

MySQL é um excelente produto e é inquestionável o seu valor e utilidade. Não tenho contra a sua utilização, só acho que é supervalorizado e sinceramente não vejo razões técnicas para endeusar o MySQL em detrimento do PostgreSQL ou MariaDB por exemplo ou mesmo SQLite (claro guardando a devidas proporções).

MySQL não é 100% público, pois tem dono a Oracle, PostgrSQL e MariaDB são totalmente 100% públicos e sem fins lucrativos.

A "hospedagem básica" de MySQL só se manteve forte e difundida pelo poder do LAMP/WAMP... Virou tradição, o MySQL é tão "pop" quanto WordPress numa hospedagem para blog, ou o uso do SQL Lite com Android. Só que existe rumores que as próximas distribuições LAMP/WAMP virão com o MariaDB. De qualquer modo, quando a "hospedagem básica" (a mais barata) oferece PostgreSQL, o preço é o mesmo que MySQL. Pode até ser mais difícil de se encontrar mais existe. O que vejo são vários provedores que oferecem o MySQL, mas sem se preocupar muito com o serviço oferecido.

O MySQL permite vários engines de storage (MyISAM e InnoDB) e cada engine tem um determinado comportamento e suas vantagens e desvantagens, o MyISAM é a mais usada, pois é simples de se utilizar, porém ela não tem ROLLBACK e InnoDB tem ROLLBACK, mas isso não ajuda tanto. Porque em qualquer caso, o MySQL tem dificuldades em manter o chamado full ACID. Ou seja, o banco de dados pode se perder em algumas situações. E mais ao se usar a InnoDB perde-se a simplicidade de configuração que seria uma das grandes vantagens do MySQL

O MySQL não pode usar 100% o conceito de banco de dados distribuído.

MySQL é totalmente fora do padrão ANSI e inventa alguma o próprio padrão que causa tremedeiras em vários administradores e programadores. Na verdade essas maluquices são as principais vantagens do MySQL, são elas que facilitam o seu uso. MySQL dá certo um monte de coisa mesmo sem saber porque. Até que você fica maluco para descobri porque não funciona mais. No MySQL existe o mais ou menos correto. Mas tem gente que gosta disso.

Bom finalizando, não quero dizer que o MySQL não presta e não deve ser usado, só acho que como tudo na vida não é a perfeição que muitos pregam. Então claro que devemos utilizar o MySQL, pois é uma software robusto, está amadurecendo e realizar o que promete. Banco de dados é como religião, política e futebol, vai de cada um. Só acho que no universo da TI temos de ser mais práticos e menos passionais e místicos.

Tem muita informação que não sabia, quem sabe é quem já passou por alguma situação em "produção" e acho interessante compartilhar Jothaz, como você fez.
Sobre as possiveis mudanças do wamp e lamp, realmente acha que vai dar certo? pois como disse o MySQL é bastante popular ao ponto de algumas pessoas estranharem esses "novos" bancos.

E quanto aos preços das hospedagens, acha que deve mudar de banco para banco?

O intuito do post foi somente apresentar alguns pontos técnicos do MySQL, que uma grande parte dos usuários desconhece e não para desqualificá-lo ou lançar um cruzada contra ele. E claro grandes empresas fora milhares de sites por ai usam o MySQL, pois certamente ele tem um enorme valor. Tentei embasar o que escrevi em pontos técnicos que podem ser contestados.

Com relação ao XAMP/WAMP adotar o MariaDB como parceiro acho que não fará nenhuma diferença pra o usuário final, pois a maioria dos usuários instalam na base do next -> next -> next -> finish. O argumento de que o MySQL é de fácil instalação na verdade pode-se traduzir que o cidadão não tem nem ideia do que instalou e nem se preocupa com o que instalou, ele que é usar. Então é inegável que XAMP/WAMP deu uma força tremenda para a popularização do MySQL. O MariaDB é irmão gêmeo do MySQL foi criado pela equipe que criou o MySQL liderados por um dos pais do MySQL Michael "Monty" Widenius. Justamente por não concordar com a venda da franquia para a Oracle. Afinal agora o MysQL tem um dono. Então seria transparente para os usuários. Agora se vai ocupar o lugar do MySQL só tempo dirá. E em funcionalidades os dois são iguais.

Então mesmo alguns puristas, xiitas, fundamentalista e integralista torcendo o nariz para os um novo banco de dados, para a maioria dos usuário instalou e funcionou esta ótimo. Do meu ponto de vista quanto mais opções, principalmente free, melhor só temos a ganhar. Eu nem uso banco de dados free, mas acho importante termo opções disponíveis. Existe uma lenda totalmente infundada de que software pago não vale a pena. Se o software for de boa qualidade e profissional vale cada centavo do seu preço.

Com relação aos preços acho que só tendem a cair. O problema que 90% dos host oferecem um serviço de péssima qualidade e amador.

Só para constar banco de dados na minha opinião: Oracle, MS SQL Server, PostgreSQL, MySQL e SQLite. Tecnicamente não vejo nenhuma justificativa para usar o MySQL ao invés do PostgreSQL. Notem que usei o termo tecnicamente, então a justificativas de qu: existem mais host´s MySQL que PostgreSQL, o MySQL é mais simples, oMysQL é mais cheorsinho kkk, não se aplica.

Sem mais...hehehe
Muito bom ler um post com tanta informação. valeu.

Deve ser complicadinho de trabalhar com um banco desses, ou não, não faço idéia....
Mas por alto, imagino que o desenvolvimento de uma aplicação se torne um pouco mais complexo e talvez mais trabalhoso...

Simples realmente não deve ser, já tinha visto algumas video aulas e é diferente do que somo acostumados a ver.

Também li algumas coisas a respeito, e surgiu outra dúvida/curiosidade: O SQLite é utilizado apenas para aplicações mobile?
O que estive lendo foi referente ao uso dele em aplicações para dispositivos móveis...

Boa tarde Marisiana, sobre o SQLite, eu não achei referencia ao uso em sistemas moveis.

Exemplos de uso do SQLite são:

Sites com menos de cem mil requisições por dia
Dispositivos e sistemas embarcados
Aplicações desktop
Ferramentas estatísticas e de análise
Aprendizado de banco de dados
Implementação de novas extensões de SQL
Não se recomenda o uso do SQLite para sites com:

Muitos acessos
Grande quantidades de dados (talvez maior que algumas dúzias de gigabytes)
Sistemas com grande concorrência
Aplicações cliente/servidor

Fonte: Wikipedia

O SQLite é muito simples pois é um banco relacional sem precisar de instalação e dependência externas.

É indicado para desenvolvimento mobile justamente por esta características.

Você pode gerenciar criar suas tabela via código ou via gerenciadores:

sqliteexpert

sqlitestudio

sqliteadmin

Algumas linguagens tipo o PHP vem com integração com ele, mas você poderá a DML(crete, insert, delete e et), comum a qualquer BD relacional para manipular gerencia seu banco de dados.

O SQLlite é simples, poderoso e de fácil utilização.

O único senão é que não impõe integridade referencial, o que dependendo da aplicação não é um problema incontornável.
Pois pode ser feito via código ou via triggers.

Para um aplicação mobile onde o bd deverá ficar local é a melhor solução pois não necessita instalação de servers ou softwares adicionais, basta criar o .db e criar sua tabelas.

Obrigada pelas informações Roniere e Jothaz!
Sanaram essa minha dúvida e mais algumas não havia questionado. =)

De nada Marisiana.

Amigo, firebird foi muito ruim antigamente, há um tempo atrás, nem SGBD ele poderia ser considerado, pois não garantia o A.C.I.D. Agora, pelo que li, ele mudou muito (pra melhor eu acho). Então, banco lento, tem várias causas; pode ser ausência de índices nas tabelas, o que gera lentidão nas consultas, o servidor do banco de dados muito sobre carregado, enfim, teria que ver mais de perto a situação. Uma coisa lhe digo, se é um projeto novo, considere mudar para mysql, se for um banco de dados muito grande (10 Gb, 100Gb 1000Gb), vá para postgres, ele aguenta o tranco na boa, e tem recursos de gente grande (oracle), como particionamento de tabelas, enfim, é um ótimo SGBD, trabalhei como DBA postgres, me surpreendi com a performance dele. Mas cada caso é um caso.

Obrigada por compartilhar tua opinião Eder!
Também tenho me surpreendido com o PostgreSQL...!

Em reply ao comentário de Roniere Almeida, também fiquei com um pouco de ciúmes do MySQL, porque sou fã do SQL Server. Porém, temos algumas coisas a considerar, como o método de cálculo deste ranking, que pode ser visto em http://db-engines.com/en/ranking_definition.
A outra coisa a considerar é que estamos na era web e mobile, e sabemos que o sistema de banco de dados mais popular para web é o MySQL. Então isto não significa que o SQL Server esteja em segundo plano; é uma questão de áreas de afinidade, pois o SQL Server é muito usado em aplicações comerciais, de missão crítica e corporativas.
Como pode ser lido sobre o método do ranking, o cálculo é feito com base no número de menções, interesse geral, frequência de discussões técnicas, quantidade de vagas de emprego, perfis profissionais em que o sistema é mencionado e relevância nas redes sociais. Acredito que seja uma questão de "boom" das aplicações web que colocam o MySQL acima na lista do ranking.

Verdade Adson, vendo por esse lado o MySQL é mais utilizado, creio que boa parte dos sistema web que rodam PHP mais da metade usam MySQL.

Verdade. Deve ser mesmo por causa da demanda web. Mas dentro da sua área e nicho de mercado, o SQL Server é imbatível.

Sem duvida, ele possui um diferencial, as edições, cada uma com suas especificidades e preços.