Segue
Em 24/07/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
escreveu:
Em Ter, 2007-07-24 às 10:25 -0300, Pablo Sánchez escreveu:
> Isso porque não existe até hoje uma implementação que convença.
Não há como haver tal implementação, porque não há conceitos que
convençam. Veja o Date a respeito.
> É o mesmo sorriso que o pessoal de Mainframe dá quando falam em usar
> Java no lugar de Cobol.
Hm, não tem muito a ver. O problema com Java é de outra natureza,
é o
de excesso de complexidade e de consumo de recursos.
Se bem que um dos problemas de OO é justamente excesso de
complexidade,
pela falta de um modelo de dados.
Exato. O modelo OO busca uma abstração muito grande, que é uma das coisas
que o tornam pesado. C++, por exemplo, no final da compilação, ao utilizar
qualquer técnica de engenharia reversa, se mostra em assembler extremamente
similar ao C, pois é uma das coisas que o compilador faz, simplificar toda a
abstração dele para poder torná-lo algo utilizável. Concordo com vc que é OO
é realmente algo pesado, que só auxilia ao programador na compreensão do
sistema, mas não ao computador na execução do mesmo.
Criar um banco totalmente OO seria quebrar com o paradigma do
> relacional de alguma forma
Não se preocupe, o SQL já o fez.
kkkkk
porém, nenhuma empresa se arrisca a investir muito nisso, já que o
> mundo é SQL.
Não é verdade, há empresas especializadas nisso. A Pick por
exemplo
recriou-se no Caché, que dizem ser OO mas é apenas um MV com Java… o que
aponta outro problema de BDOO: é um retrocesso ao mundo pré-relacional,
abandonando as abstrações relacionais por preocupações físicas.
Sim, mas o Caché mantém a camada não OO. Bancos 100% OO são difíceis de
encontrar até, porque não há muita compatibilidade com os mesmos.
Quem sabia SQL há 15 anos, ainda usar numa boa aquele basicão.
SQL, com todos seus defeitos, é muito mais simples e poderoso que
qualquer linguagem de manipulação de dados OO, justamente por sua
herança relacional. E seus problemas são principalmente derivados de
seus desvios do modelo relacional.
> Agora, quem programa proceduralmente, já não consegue se virar tão bem
> com OO porque exige uma forma distinta de refletir o mundo.
Mas OO *é* procedural.
...
Só tento a paciência para ler este documento curioso
> http://s2k-ftp.cs.berkeley.edu:8000/postgres/papers/ERL-M85-95.pdf
Não entendi o que você quis dizer.
Foi esse artigo aliás que arruinou o Ingres original. Todos os
benefícios que tentaram decorrentes de OO teriam sido melhor obtidos com
o aperfeiçoamento do Ingres QUEL, sem as limitações que o QUEL OO e o
SQL impuseram.
O Stonebraker é um ótimo programador, mas nunca entendeu
totalmente o
modelo relacional e suas implicações. Vide as discussões de Date,
Darwen e McGoveran a respeito.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
