#+BEGIN_EXAMPLE
>>>>> "GF" == Guimarães Faria Corcete DUTRA, Leandro writes:
#+END_EXAMPLE
#+BEGIN_EXAMPLE
GF> Mas aí é um problema ou de um modelo ruim (inconsistente), ou
GF> incompleto (faltam as visões [VIEW]s que dêem os resumos que o
GF> programa precisa) ou de um programa ruim. Ou de qualquer combinação
GF> dessas três.
#+END_EXAMPLE
Nem sempre, as vezes o domínio do negócio utiliza um formato mais
adequado pra manipulação dos dados num meio fora do banco relacional,
seja por abstração ou custo de implementação. Por exemplo, um grafo
renderizado para SVG, é muito melhor transformar os dados do grafo
dentro do banco em algum formato aceito por uma biblioteca que cuide da
tarefa de gerar o SVG pra você. O que você está alegando é que o texto
do SVG (ou o binário de um PNG) teria que sair pronto de dentro do banco
com uma única consulta produzida por uma view ou função, e eu até
concordo, o problema é que isso nem sempre prático ou barato em termos
de engenharia. Por exemplo, já mencionaram numa outra thread que essa
abordagem não escala bem. Esse trabalho de ETL e integração com o mundo
externo encontra problemas recorrentes, e por isso faz sentido ter
bibliotecas que abstraiam esses problemas. Desde que isso não influencie
o projeto ideal do banco com idéias infundandas, não há problema algum.
#+BEGIN_EXAMPLE
GF> Isso porque não há abstração de dados melhor que a relacional.
#+END_EXAMPLE
Há controvérsias, novamente, o que eu entendo é que isso depende do meio
onde o acesso a dados está sendo feito. Por exemplo, árvores
implementadas através de ponteiros são a melhor forma de se abstrair
dados hierarquicos em memória, em diversos casos, e por isso vale a pena
extrair a árvore de dentro do banco e reconstruí-la em memória para
depois executar a lógica de negócio. Talvez o que você quis dizer é que
não há abstração de dados melhor para persistir dados genéricos, e eu
concordo plenamente (mesmo assim, ainda há controvérsias).
#+BEGIN_EXAMPLE
GF> OO é uma falsa abstração, na verdade ela volta para o físico o
GF> que, em SQL, é ao menos parcialmente lógico…
#+END_EXAMPLE
Isso é análogo a afirmar que escrever código em binário é melhor do que
escrever C porque está mais próximo do que acontece fisicamente,
novamente, eu até concordo, sob a ótica de implementação ideal. O
problema é que a nível de custo de projeto, raramente é viável
implementar lógica de negócio num meio mais próximo do físico.
#+BEGIN_EXAMPLE
GF> O problema é que ORM não dá essa boa abstração, como acabo de
GF> (tentar) explicar alhures nesta discussão.
#+END_EXAMPLE
"ORM" estritamente falando, talvez não, mas um toolkit de ETL pode vir a
ser adequado em diversos casos sim.
Eden Cardim
+55 11 9644 8225
e...@insoli.de
--
[[http://insoli.de][Insolide Soluções de TI Ltda.]]
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
