Segue
Em 24/07/07, Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
escreveu:
Em Ter, 2007-07-24 às 14:18 -0300, Pablo Sánchez escreveu:
> 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.
Simples. Date, _An Introduction to Database Systems_; sem contar
Darwen, Pascal, McGoveran, até Codd.
Isso está no histórico da finada lista nossa antecessora várias
vezes,
mas para resumir o SQL não é relacional porque tabelas não são relações.
Isso gera uma complexidade adicional e uma falta de flexibilidade que as
pessoas, por não conhecerem o modelo relacional, querem gambiarrar de
várias formas: OO, XML, MV…
Bom, não participava da lista antes. Vou procurar me atualizar com os dados
antigos (?), hehehe.
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.
Por que não?
Porque no conceito de OO, visão está mais para um grupo de objetos, e a
idéia aqui é você ter o Objeto, e não um grupo de.
OLAP é um tipo de processamento feito sobre dados consolidados
Não necessariamente. OLAP é o processamento independente da forma
dos
dados; e é muito mais flexível sobre a base normalizada. Desempenho
lida-se com índices e visões materializadas.
Sim, pode ser feito assim, mas a velocidade será sofrível, por isso é melhor
nem definir a possibilidade disso para não perder uma idéia boa com uma má
implementação sobre algo que não deveria ser assim.
(algo que faz muito mais sentido que visão).
E o que é uma visão materializada senão uma consolidação?
Ok, me pegou nessa. ;-)
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.
O que é outro problema de modelagem, embora não no nível da
normalização. CQD.
Nesse caso já se entra em infraestrutura de redes, e tem-se que pensar que
nem todo mundo tem condições de encomendar um sistemão hiper-mega-integrado.
Aí, vale a pena tapar o sol com a peneira e implantar um BI semi pronto como
um Pentaho ou algo do gênero.
É 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
Nenhuma dificuldade. É só que OO (1) não tem conceitos sólidos e
(2)
não tem conceitos de dados.
Se o 1 e 2 eram para links, faltaram.
Desafio que o Pascal sempre faz: referencie uma boa definição de
modelos de dados. Nunca vi, e olhe que estou na área desde que OO a
gente só ouvia falar, 93 para ser preciso.
Os conceitos de OO são bem mais antigos que isso, apenas tiveram penetração
mais lenta no Brasil, e uma grande aceleração por conta de internet, etc e
tal. Mas você tem conceitos de OO de 1982, por exemplo.
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...
Nah… fico espantado com os ofendidos justamente por não ver motivo
de
ofensa. É difícil me surpreender.
Ok. Me senti ofendido pois me chamou praticamente de arrogante ao ponto de
me achar um guru, ou ignorante ao ponto de não sê-lo. Então era uma faca de
dois gumes para ofender alguém. Mas deixa pra lá.
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.
Não é só isso. Entre resolver um problema e acrescentar uma
alternativa, o PHP fica com a alternativa. Isso é muito ruim para
segurança, por exemplo, mas principalmente para a integridade conceitual
— que é onde a falta de conceitos relacionais pega.
Na verdade, PHP fica com o fato de ser uma linguagem de programação, e não
um framework. Esse é um erro comum das pessoas. C e C++ também são apenas
linguagem, mas várias empresas apresentam um conjunto de ferramentas que
facilitam a vida. Da mesma forma, PHP. Ele tem um conjunto básico de funções
e uma penca de outras adaptações são feitas em cima. Até uma implementação
de Struts em PHP eu já vi, coisa mais feia da face da terra.
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...
De modo algum, estou pouco preocupado com qualquer
implementação. Mas
essa área toda é um grande engodo, extremamente mal definida; basta
verificar que ORM não tem nada a ver com relacional (só com SQL), e que
o modelo relacional em si já atende todas as necessidades OO, como
provado por Date e Darwen no Terceiro Manifesto (_The Third Manifesto_).
A questão é que uma classe é um tipo — ou seja, um domínio e seus
operadores. Aliás aqui, mea culpa, falei domínio quando deveria ter
dito tipo. E você pode até lidar com tipos de relações, mas isso é
contraproducente, por ficarem tipos muito complexos.
Ok, porque o conceito de Domínio está mais na parte de Namespaces do que na
parte de classe. Agora, dizer que tipos complexos são contra-producentes é
problemático... entendo que quanto maior a complexidade do sistema, maior
será a dificuldade de manutenção do mesmo, seus dados e etc. Mas não há como
não produzir sistemas complexos, pois os problemas a serem
Tio Codd sabia das coisas.
> 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.
Não existe normalização em excesso; existem são limitações do SQL,
e
ainda limitações das implementações do SQL.
Claro que existe! Começa pelo fato de normalizar o que não é preciso,
pensando em um futuro distante, remoto e praticamente inexistente onde
aquele atributo poderia ter que ser múltiplo, e pela implementação disso.
De qualquer maneira, tua afirmação é genérica e não contrapõe o que
escrevi.
Não, não contrapõe, mas não dá apoio.
Um abc!
Obs: to gostando da discussão com vc. :-D
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
