Segue abaixo
Em 24/07/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
escreveu:
Em Ter, 2007-07-24 às 10:19 -0300, Pablo Sánchez escreveu:
> Melhor a gente não entrar na discussão
Então é melhor nem escrever aqui, porque esta é uma lista *de
discussões*…
Duh, sério?!
porque até onde eu saiba PostgreSQL é um banco Objeto Relacional
Então, não pode ser relacional — em que pese a documentação —
porque
SQL não é relacional.
... Cara, de boa, de onde vc anda tirando seus conceitos, porque eu
realmente estou tendo dificuldade em acompanhar seu raciocínio.
É objeto, mas justamente o que está provado é que isso não é muito
útil
e ainda prejudica os modelos de dados e seu uso por programas e
usuários.
Provado onde?
Criar um sistema pensando em insert, update, delete, etc, acho que já
> deu para entender que não estamos falando de dados consolidados...
Na verdade não exatamente — o que quis dizer é que a visão que
você tem
de todos os dados de pessoa física com herança OO, você tem numa visão.
... Não. Mas blz, vamos continuar...
Para dados consolidados, melhor criar um OLAP, pegar um Bizgres e
> mandar ver.
Não… OLAP é simplesmente um tipo de processamento; o que você quis
dizer foi um /data warehouse/. Mas justamente está provado que a maior
parte dos /data warehouses/ só é necessário justamente por problemas de
modelagem (falta de normalização) e por não se usarem ferramentas como
as visões materializadas.
OLAP é um tipo de processamento feito sobre dados consolidados (algo que faz
muito mais sentido que visão). E Data Ware House não é usado apenas onde
está mal modelado, mas, e um grande mas aqui, em lugares onde você tem
diversos sistemas distintos com massas de dados que precisam ser integrados
de alguma forma para criação de informações de valor gerencial. Se você tem
um local onde seu sistema de Contas a pagar é diferente do seu sistema de
Controle de Estoque, então vale a pena você implementar um DW. DW é para
uniformizar as informações de diversos sistemas em um conjunto de
informações gerenciais úteis e válidas, além de históricas, ou seja, dados
consolidados. E a forma mais apropriada de consultar é através de um OLAP.
Então, se eu falo para usar um OLAP com dados consolidados, para mim ficou
implícito a criação de um DW, definição de ETLs e tudo mais...
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...
É o correto, porque é o conforme ao modelo relacional. Dá mais
flexibilidade, desempenho, e transparência ao modelo de dados.
Sim, mas o modelo em questão é OO. Acho que você está com dificuldades em
enfrentar sistemas OO, o que nos levaria ao ponto de partida, mas sério, não
vou entrar nesta discussão neste ponto.
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
Queria saber por que no Brasil as pessoas tomam críticas técnicas
como
pessoais. Só se você ficou ofendido por não ser um guru?
Difícil responder a você sem ofender nesta...
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.
Não apenas de implementação, mas de conceitos. E pior ainda, de
cultura.
O problema do PHP tem sido a facilidade de acesso a ele em comparação a
outras tecnologias, o que atrai um contigente enorme de novatos que por
conseguir receber os dados de um formulário qualquer e salvar em um banco,
criam uma série de pseudo-profissionais.
Por exemplo, você está incorrendo num dos Dois Grandes Erros do Date
(/Great Blunders/), que é de mapear classes para relações; classes são
domínios.
Só se você considera classes algo nada além da struc do C. Classes também
trabalham na questão de ORM (Object-Relational Mapping), ou se não o
fizessem, não teriam persistência...
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.
Tabelas herdadas, certamente, porque muitas operações que num
modelo
relacional vão trabalhar com um conjunto de dados menor no OO vão ter de
varrer mais disco e trazer mais dados para memória.
Isso vai ficar mais aparente em alta concorrência ou em pesquisas,
neste caso porque você está predeterminando um caminho de acesso,
efetivamente desnormalizando a base.
Normalização não é a chave de tudo. E outra: normalização em OO é possível,
e factível. Só que normalização em excesso, como você bem sabe pelo que pude
sentir da sua experiência, causa mais transtornos que ajudam.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
