Por favor, RFC 1855… siga o exemplo…
Em Ter, 2007-07-24 às 15:29 -0300, Pablo Sánchez escreveu:
> > 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.
Visão no relacional, entre outros benefícios, agrupa informações, por
exemplo as de pessoa física no seu caso. Ou seja, a sua negativa não se
aplica porque eu estava falando das visões SQL.
> 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.
De maneira alguma, há ótimo desempenho em visões materializadas. Por
que você acha que nã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.
>
> 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.
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.
>
> Se o 1 e 2 eram para links, faltaram.
Só enumeração mesmo.
> 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.
Bem antes até… eu li coisas dos anos 70. A questão não é idade; é que
*não existe* um modelo conceitual de dados OO. Aliás, a rigor nem
existe um SGBDOO, a rigor o que é vendido como tal são, na prática,
SDKs.
> 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á.
Não, só pedi dica dos gurus de programação porque tenha a forte
impressão de que há uma maneira melhor de fazer a coisa, mas não sou da
área há tempos, portanto não vou me arriscar.
> Ok, porque o conceito de Domínio está mais na parte de Namespaces do
> que na parte de classe.
Não, a menos que nalguma subcultura OO. Domínios são listas de valores
(conceitualmente, não fisicamente); tipos são domínios mais seus
operadores, e é isso exatamente uma classe — estruturas de dados e
métodos.
> Agora, dizer que tipos complexos são contra-producentes é
> problemático...
Não, tipos complexos podem ser necessários e bons. O que não vale a
pena é mapear classes como relações — porque você perde o poder e
abstração do modelo relacional.
> 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.
E termina onde?
Normalização é essencialmente organização. Se você acha que uma
necessidade futura é muito remota, pode ignorá-la, desde que tenha
consciência do custo futuro em relação às economias presentes. Isso é
outro assunto, muito mais de gestão que de normalização.
> 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.
Então… queria argumentos bem sólidos. Me frustra que há anos nesta
lista (suas antecessoras, na verdade) aparece essa discussão e nunca há
uma argumentação conceitual sólida do lado de OO.
E isso porque não sou formado em Ciências da Computação…
> Um abc!
>
> Obs: to gostando da discussão com vc. :-D
Ufa, não gosto quando estressa!
--
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
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
