Le 2012-9-12 16h37, Eden Cardim a écrit :
>
> Meta-resposta: Existe padrão de resposta de email sancionado por alguma
> organização relevante?
RFC 1855 e outros que me fogem à memória…
> 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.
Por outro lado, as inconsistências causadas por atualizações que passam
por fora das regras que estão nas aplicações também…
> 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
E isso não tem nada a ver com o que discutimos, uma vez que a
transformação não tem nada a ver nem com o modelo relacional, nem com
orientação a objetos.
> é 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.
E esse ‘sic’ aí mostra que estás forçando o termo. O que só está
gerando confusão, e não contribui para a discussão.
Use as bibliotecas que quiser, faça as transformações que quiser, mas
isso não é mapeamento objeto-relacional.
> 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.
Precisas demonstrá-las. Mas não são falácias, são a experiência. Duas
décadas dela.
> 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
E o que isso tem a ver com essa transformação? Ou boiei…
> 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.
Tu teimas em chamar meras transformações em mapeamento. Aí não dá para
discutir, por simples falta de sentido quando se dá aos termos o
significado que bem se entende, e não o convencional.
Veja, se chamas qualquer biblioteca de transformação de ORM, não provas
que ORM é necessário. Só que bibliotecas de transformação são necessárias.
> 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.
Certo.
> 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.
Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o
que queremos, e podemos criar tipos abstratos de dados, isolando
aplicações de muitas mudanças nos tipos e nas estruturas base, físicas e
até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer,
o que acaba por nos dar o problema das classes base mutantes…
--
skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org
+55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
