>>>>> "LD" == Leandro DUTRA, Guimarães Faria Corcete writes:
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 LD> E o que isso tem a ver com essa transformação? Ou boiei… O que tem a ver é que mapeadores facilitam a integração com pontos de entrada de dados em bibliotecas OO externas ao banco de dados que realizam as transformações, evitando assim que essa integração precise ser reimplementada por inteiro para cada projeto. O meu argumento é de que esse tipo de integração é uma aplicação perfeitamente válida de mapeadores, até dos mais ruins. A alegação anterior era: EC> parte dos casos, não existe saída fácil. Mas existe um problema EC> recorrente em desenvolvimento que é inflar os dados normalizados do EC> banco pruma estrutura de dados sã que o teu software pode consumir, e 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. E isso nem sempre é verdade, muitas vezes os dados precisam de transformações complementares aos resumos das views, isso não implica em um "programa ruim" ou modelo incompleto, e é um caso onde é razoável utilizar mapeadores como mecanismo de integração. LD> Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o LD> que queremos, e podemos criar tipos abstratos de dados, isolando LD> aplicações de muitas mudanças nos tipos e nas estruturas base, físicas e LD> até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer, LD> o que acaba por nos dar o problema das classes base mutantes… Poderia se argumentar que existem implementações de OO que também possuem essas propriedades, caso fosse o tópico. Porém, seria irrelevante numa discussão objetiva, pois objetividade requer métrica. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral