>> Melhor se desenvolver com uma camada abstraindo o banco.
>
> Pior, a aplicação fica mais peſada e frágil, e o banco menos
> conſiſtente.
>

Não necessariamente, do pouco que conheço, o SQL Alchemy(feito em
Python), abstrai o que é possível, mas permite que se use recursos
únicos do SGBD em questão.


>> Melhor ainda se desenvolver abstraindo entre banco relacional
>
> Não há bancos relacionais hoje, é tudo SQL.

Eu me referia então aos bancos SQL. Pelo que já vi no seu histórico
aqui na lista, você sabe bem melhor que eu essa questão, nem discuto
:) .

>> e as criaturas alternativas tipo CouchDB.
>
> Qual o ganho?  Só vejo prejuízos, me parece coiſa de quem não conhece o
> modelo relacional nem a tecnologia SQL.  Ou eſtou errado?

Na verdade, aqui entra a minha parcialidade pró-postgres.

O caso é que a maioria dos projetos open-source é baseado no mysql que
tem muito menos recursos avançados em relação ao PG. Então acontece
que temos sistemas que são feitos para um único SGBD, mas o pior não é
isso, e sim que esse único tem menos recursos que os demais. Então
ficamos limitados por baixo.

Quanto a questão de não conhecerem SQL, concordo e acrescento: tão
logo esse tipo de banco tipo couchDB se torne mais popular, problemas
vão surgir devido ao fato que o problema real é que as pessoas querem
armazenamento infinito, sempre disponível e com rápido acesso. Mas
essas pessoas não querem precisar estudar sobre o armazenamento.
Claro, há exceções, mas no geral é isso.

Para mim a única real vantagem que produtos como CouchDB tem sobre
bancos SQL é que são pensados desde o início para escalar.

Outra característica é que esse tipo de banco se adequa melhor ao
modelo OO, não existe o clássico problema de se mapear algo OO para
algo orientado a tabelas e linhas. Mas isso é questão de conhecer o
que se usa, e não ficar culpando um banco SQL por não se encaixar
direitinho ao Java*-way-of-life.

*Pessoal de Java que costuma ser o mais reclamão disso ;).
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a