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…
> 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?
> 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.
> (algo que faz muito mais sentido que visão).
E o que é uma visão materializada senão uma consolidaçã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.
O que é outro problema de modelagem, embora não no nível da
normalização. CQD.
> É 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.
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.
> 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.
> 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.
> 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.
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.
De qualquer maneira, tua afirmação é genérica e não contrapõe o que
escrevi.
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation.
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
