>>>>> "GF" == Guimarães Faria Corcete DUTRA, Leandro writes:
GF> Metacomentário: que formato estranho! É padronizado algures? Meta-resposta: Existe padrão de resposta de email sancionado por alguma organização relevante? GF> Não, é só ter o tipo adequado. E o PostgreSQL nos permite criar GF> tipos… muitas das ditas extensões chamadas NoSQL para o PostgreSQL não GF> passam de novos tipos. Certo, porém acrescentar novos tipos ou alterar os existentes sem downtime da base costuma, na minha experiência, ser administrativamente mais custoso do que atualizar código numa aplicação desacoplada. No caso, depende da competência administrativa dos recursos que você tem disponível pro projeto, se essa administração é trivial de realizar, você tem um bom motivo para usar tipos específicos de negócio, sim. Esse porém, nem sempre é o caso. GF> Não mesmo. Não entendi porque a base teria de gerar o SVG quando os GF> dados do grafo estão na base. Porque alguém precisa dos dados em forma de SVG, logo, alguma parte do sistema precisa transformar o grafo armazenado em relações num documento SVG. E não é trivial realizar essa transformação usando SQL, é menos trivial usar SQL para produzir um formato intermediário e depois converter esse formato no produto final (o SVG). É nessa transformação que um "ORM" (sic) é útil. GF> Ainda não as encontrei por parte de quem conheça o modelo relacional. GF> Normalmente quem controverte mal conhece SQL — conhece no máximo como GF> programador, não como modelo de dados. 3 falácias retóricas na mesma sentença, assim fica difícil… Permance o fato: é controverso. GF> Até aí morreu o Neves. Novamente, qual o problema de transformar os GF> dados fora da base? Isso nada tem a ver com as regras organizacionais GF> (‘de negócio’), ou com o mapeamento OR. Discordo, tem tudo a ver, porque quando se desenvolve orientado a objetos você precisa de um ponto de entrada dos dados no seu modelo OO, de uma forma ou de outra. Se você vai fazer isso manualmente ou não é uma outra questão, mas o "mapeamento" está sempre presente, usando "ORM" (sic) ou não. O problema está na forma como os "ORM" (sic) mais conhecidos abstraem essa transformação, mas é perfeitamente possível existirem abstrações razoáveis pra esse tipo de operação. GF> Não há ‘dados genéricos’. O que há é uma autolimitação por parte de GF> quem não sabe criar tipos… Há também uma limitação administrativa de se manter e atualizar tipos em ambientes de produção. O que eu geralmente faço é introduzir tipos onde se tem muita certeza da estabilidade dos requisitos de uma determinada parte do sistema, caso o ROI da introdução seja justificado. GF> Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? Não concordo que SQL seja mais abstrato. É mais formal, porém não mais abstrato. Porém isso é difícil de medir objetivamente. Eden Cardim +55 11 9644 8225 [email protected] -- [Insolide Soluções de TI Ltda.]: http://insoli.de
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
