Segue:
Em 24/07/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
escreveu:
Em Ter, 2007-07-24 às 09:45 -0300, Pablo Sánchez escreveu:
> Originalmente, o Postgres era um banco OO, que depois veio a ter
> suporte para o SQL, ou seja, foi a inserção do modelo relacional em um
> modelo OO.
Não mesmo!
Inicialmente era relacional, Ingres com QUEL; depois, perdeu a
pureza
relacional com as extensões OO, foi o Postgres com PostQUEL; aí perdeu
de vez o relacional com o SQL, o PostgreSQL com SQL.
Melhor a gente não entrar na discussão, porque até onde eu saiba PostgreSQL
é um banco Objeto Relacional, e a história e documentações sobre a
implementação de 1986 já focavam nessa direção. Só que essa é uma discussão
para um boteco, tomando uma gelada, no final do expediente, hehehe. :-D
Porque, aja assunto nesse item...
De toda a forma, o que fiz foi o seguinte:
>
> 1 - Contrução de uma classe em PHP a partir de uma classe abstrata
> chamada Persist. Esta classe automatiza toda a construção de SQLs para
> SIUD (select, insert, update, delete - quem usar a terminologia crud
> para cima de mim apanha!).
>
> 2 - Contrução de uma outra classe PHP a partir da nova classe PHP.
> Então, não há porque eu recriar toda uma tabela se eu já tenho uma
> classe original. Ex: Persist <- Pessoa <- PessoaFisica. O que faço é
> PessoaFisica (campos) inherits(Pessoa).
Isso se faz com uma tabela pessoa_física que, vem vez de herdar
pessoa,
referencia-a com uma chave estrangeira.
Como pôde ver mais abaixo, essa foi a solução para outros bancos.
Se você quiser os dados consolidados, isso é uma visão.
Criar um sistema pensando em insert, update, delete, etc, acho que já deu
para entender que não estamos falando de dados consolidados... Para dados
consolidados, melhor criar um OLAP, pegar um Bizgres e mandar ver.
Para outros bancos, o que tive que fazer foi que, crio uma tabela
> chamada Pessoa, e outra chamada PessoaFisica apenas com os atributos
> que são distintos de Pessoa, e coloco a chave primária de PessoaFisica
> como sendo uma chave estrangeira que referencia a primária de Pessoa,
> já que outros bancos não tem essa implementação OO. Imagino que a
> solução que vc está sugerindo seria algo como esta.
Exato, é o correto.
Nops, não é o correto, é o tradicional, o que na raiz já quer dizer que não
é necessariamente o correto, é apenas como já se faz há anos...
Agora vem o grande problema que é na implementação fora do
> servidor...
> A performance nesse segundo caso é muito mais baixa na linguagem
> (PHP), pois serão necessárias n aberturas (n = número de heranças
> existentes das classes) de requisições ao servidor para ir preenchendo
> os dados, além da classe PessoaFisica ter que criar uma classe Pessoa
> para fazê-la carregar os dados e importá-los/copiá-los para seus
> atributos. Se houverem n classes das quais eu fui herdando, o espaço
> ocupado na memória vai também subindo exponencialmente. Utilizando
> heranças de tabelas, fica apenas uma requisição, à tabela
> PessoaFisica, pois ela já terá todos os atributos necessários.
Suspeito que o uso de visões vai resolver tudo — mas de qualquer
maneira é um problema ou do PHP, ou da maneira como você o usa.
Na verdade, tratou-se de uma limitação no tratamento de escopo para chamada
de métodos na classe pai. A referência parent no PHP, infelizmente trata do
parent de onde foi implementado o método, e não do parent da classe que está
chamando o método. Isto é, ao criar Persist <- Pessoa <- PessoaFisica, se a
implementação de load foi feita em Persist, ao chamá-lo em PessoaFisica, ele
ao invés de tratar a referência de parent como o parent de PessoaFisica (ou
seja, Pessoa), vai buscar um pai inexistente em Persist, dando erro. Por
isso acabou ficando um gateado feio que só, mas que funciona 100%.
Peço aos gurus de programação que dêem sugestões aqui. Se bem que,
pelo que eu saiba, guru de programação quer distância de PHP…
Não vou entrar nesta discussão, porque acho que querer invalidar uma
tecnologia com um ataque tão fraco já resume tudo. Afinal de contas ao dizer
uma coisa tão absurda, você está também me atacando, já que programo em
C/C++, Java, C#, e outras tecnologias que acho que você nem tem idéia que
existiam, e considero PHP uma linguagem muito boa, apesar de algumas falhas
de implementação.
Assim, teria que ser pesado quão mais lento isso fica no Postgres
> antes de qualquer conclusão. :-/
No PostgreSQL não tem problema.
Acho que você não entendeu o que eu quis dizer... Me referia a verificar se
fica mais pesado utilizar tabelas herdadas ou tabelas referenciadas, uma vez
que o uso das múltiplas tabelas deixa mais pesado com certeza para o PHP.
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
