[Cascavel-pm] Banco de dados

[Nilson Santos Figueiredo Junior]

On 6/27/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
>    Nem para tudo. Você não podia usar um subquery como uma tabela.

A minha opinião é que, se você está fazendo isso, deveria ter criado uma view.

>    Nossa, grande vantagem. É a única situação em que eu não me importo
> com performance: quando estou desenvolvendo sistemas (e, portanto, sou o
> único usuário do sistema)

Sim, é uma grande vantagem considerando que é uma biblioteca de uns
300kb que você embedar em seus programas. Ao escrever aplicações
desktop, ao invés de você usar alguma biblioteca tosca e limitada de
armazenamento de dados você pode ter todos os benefícios de um banco
de dados relacional.

E se o banco de dados for algo somente leitura, o desempenho continua
ótimo. O problema do SQLite é que, pra escrita, ele dá um lock no
arquivo inteiro (ou seja, no banco de dados inteiro). Por isso a
utilização concorrente em aplicações com muita escrita fica
prejudicada.

>    Apenas de boa parte dos sites de internet. Mas, normalmente, para
> estas situações, o maior tempo de espera é a latência de rede, o que faz
> a vantagem ser praticamente nula... eu acho.

O problema não é latência propriamente dita, é carga nos servidores. A
latência fica grande quando a carga nos servidores está alta. A
transmissão pela rede dos dados é algo que não vai gastar mais de 1
segundo. Mas quando a base de dados começa a apresentar problemas de
performance, as queries que irão compor a resposta começam a demorar
mais que isso.

E não é tão simples assim fazer o sistema escalar, jogar mais hardware
dá um ganho linear, enquanto os problemas de performance aumentam de
forma no mínimo quadrática.

De fato, em sistemas web de grande utilização, o tempo de latência de
rede é o menor dos problemas. Tudo mais costuma causar problemas de
performance, menos isso.

-Nilson Santos F. Jr.