2012/9/12 Eden Cardim <[email protected]>: >>>>>> "GF" == Guimarães Faria Corcete DUTRA, Leandro writes: > > GF> Mas aí é um problema ou de um modelo ruim (inconsistente), ou
Metacomentário: que formato estranho! É padronizado algures? > 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 Não, é só ter o tipo adequado. E o PostgreSQL nos permite criar tipos… muitas das ditas extensões chamadas NoSQL para o PostgreSQL não passam de novos tipos. O que não as diminui de modo algum; só fico ressabiado porque ao falar de extensões NoSQL em vez de tipos SQL acabamos por diminuir indevidamente o SQL e, por extensão, o próprio modelo relacional (que já é bem mais poderoso que o SQL…). > 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 Não mesmo. Não entendi porque a base teria de gerar o SVG quando os dados do grafo estão na base. > GF> Isso porque não há abstração de dados melhor que a relacional. > > Há controvérsias, novamente Ainda não as encontrei por parte de quem conheça o modelo relacional. Normalmente quem controverte mal conhece SQL — conhece no máximo como programador, não como modelo de dados. > 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. Até aí morreu o Neves. Novamente, qual o problema de transformar os dados fora da base? Isso nada tem a ver com as regras organizacionais (‘de negócio’), ou com o mapeamento OR. > Talvez o que você quis dizer é que > não há abstração de dados melhor para persistir dados genéricos Não há ‘dados genéricos’. O que há é uma autolimitação por parte de quem não sabe criar tipos… > GF> OO é uma falsa abstração, na verdade ela volta para o físico o > GF> que, em SQL, é ao menos parcialmente lógico… > > 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, Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? > "ORM" estritamente falando, talvez não, mas um toolkit de ETL pode vir a > ser adequado em diversos casos sim. Nunca falei nada contra ETL… _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
