gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
Soluções de Data Warehousing
Contribuído por scorpio em 17-03-04 21:07
do departamento do-it-with-OSS
perguntas Mojo_risin escreve "Alguém conhece alguma solução OLAP para Unix/Linux gratuita? Pelo que eu sei os principais líderes são o SAS (business intelligence) e o Clementine, que além de serem caríssimos, desconheço se existe uma versão Unix, principalmente o SAS, uma vez que o Clementine está implementado em Java. "

O TCP está morto. Viva o BIC-TCP!!! | Os mitos do open source no plano comercial  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Mojo_risin
  • Mais acerca perguntas
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    golap (Pontos:3, Interessante)
    por leitao em 17-03-04 22:17 GMT (#1)
    (Utilizador Info) http://scaletrix.com/nuno/blog/
    Tambem ja' andei 'a procura -- a unica coisa que vi foi o golap -- mas nunca andou para a frente...


    "I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information

    Open Source OLAP (Pontos:5, Interessante)
    por mvalente em 18-03-04 0:08 GMT (#2)
    (Utilizador Info) http://www.ruido-visual.pt/
    Alguém conhece alguma solução OLAP para Unix/Linux gratuita? Pelo que eu sei os principais líderes são o SAS (business intelligence) e o Clementine, que além de serem caríssimos, desconheço se existe uma versão Unix, principalmente o SAS, uma vez que o Clementine está implementado em Java

    Sim, o SAS tem uma versão para Linux. O Essbase da Hyperion (lider de mercado) tb está portado para Linux. A Applix tb já chegou a ter, nao sei se mantém.

    Free/Open Source é q nao há mta coisa: tens o Lemur (C++, alpha) e o Mondrian (Java, versao 1.0 de Agosto passado)

    Cumprimentos

    Mario Valente

    case study (Pontos:4, Interessante)
    por ruben dig em 18-03-04 11:35 GMT (#3)
    (Utilizador Info) http://www.floppy.com.pt
    se alguém quiser ler um case study do spss clementine aplicado no Banco Espirito Santo :

    http://www.spss.com/succe ss/template_view.cfm?Story_ID=74


    ah pois... olap é mais complicado... (Pontos:3, Interessante)
    por Vx em 18-03-04 15:18 GMT (#4)
    (Utilizador Info) http://www.valfreixo.org
    Essbase da Hyperion.. agora gratuito é que és capaz de ter problemas. Ou estão demasiado alpha ou pré-alfa ou então são tão abertos a customização que fica mais barato (custo homem/hora) comprares uma solução comercial. Ah.. e ha as soluções Java que pesam e pesam e pesam e pesam.. (isto do java é uma opinião pessoal nao me crucifiquem já). Eu aconselhava a veres com atenção as ofertas comerciais e veres que se calhar vale a pena implementar mesmo suportando os custos. Acaba por ficar mais barato que uma solução totalmente open source mas nao testada que vais demorar mais tempo a limar arestas e a customizar a coisa que vai acabar por ficar mto mais caro. mas isto sao os meus dois centimos....
    Re:ah pois... olap é mais complicado... (Pontos:1)
    por Mojo_risin em 19-03-04 12:48 GMT (#5)
    (Utilizador Info)
    Também me parece que, por enquanto, pôr uma das soluções indicadas a fazer o que se quer, vai exigir uma grande quantidade de tempo ou não será possível. Quanto às soluções em Java, também concordo contigo excepto em relação a ser uma opinião pessoal, porque acho que é bastante objectivo que as aplicações pesam e não é pouco! Além disso, a interface gráfica é um pouco desagradável se for feita em AWT ou Swing, mas isso são pormenores :-) De qualquer maneira acho que actualmente o mais viável é ainda escolher uma boa solução comercial existente no mercado. Obrigado a todos pelas referências!
    Re:ah pois... olap é mais complicado... (Pontos:3, Informativo)
    por CrLf em 19-03-04 13:41 GMT (#6)
    (Utilizador Info) http://crodrigues.webhop.net
    porque acho que é bastante objectivo que as aplicações pesam e não é pouco

    Isso não é verdade, já foi. As versões mais recentes do JRE tiveram aumentos muito significativos de performance, tanto no arranque (um calcanhar de Aquiles tradicional do Java) como durante a execução (onde, devido aos melhoramentos na HotSpot VM, o Java consegue agora ser mais rápido do que -- alguns -- programas nativos depois de algum tempo de execução).

    Além disso, a interface gráfica é um pouco desagradável se for feita em AWT ou Swing

    Eu por acaso não acho o Metal assim tão mau mas este é apenas um theme. Se queres ter aplicações Swing com melhor aspecto podes usar o Looks para Swing (webstart demo). Penso que este pacote é o que é usado no software de IRS deste ano.

    -- Carlos Rodrigues
    Re:ah pois... olap é mais complicado... (Pontos:1)
    por Mojo_risin em 20-03-04 17:00 GMT (#7)
    (Utilizador Info)
    Isso não é verdade, já foi. As versões mais recentes do JRE tiveram aumentos muito significativos de performance, tanto no arranque (um calcanhar de Aquiles tradicional do Java) como durante a execução (onde, devido aos melhoramentos na HotSpot VM, o Java consegue agora ser mais rápido do que -- alguns -- programas nativos depois de algum tempo de execução).

    É verdade que houve melhorias notáveis na máquina virtual do Java mas, IMHO, a sua performance ainda está muito longe de aplicações implementadas em C/C++ ou outras linguagens compiladas, pelo que se puder escolher não opto pelo Java.

    Eu por acaso não acho o Metal assim tão mau mas este é apenas um theme. Se queres ter aplicações Swing com melhor aspecto podes usar o Looks para Swing (webstart demo). Penso que este pacote é o que é usado no software de IRS deste ano.

    Estou impressionado! Até hoje tinha apenas experimentado utilizar o "system" look & feel e não tinha nada a ver com isto...
    Não é exactamente igual ao XP nativo mas é de grande qualidade.
    Choose your weapons (Pontos:2)
    por CrLf em 20-03-04 20:15 GMT (#8)
    (Utilizador Info) http://crodrigues.webhop.net
    a sua performance ainda está muito longe de aplicações implementadas em C/C++ ou outras linguagens compiladas, pelo que se puder escolher não opto pelo Java.

    Como em tudo, isto depende:
    1. Se a aplicação tem um longo tempo de execução, se uma ligeira penalização de performance inicial é aceitável e não há constrangimentos de memória (não só do hardware onde o sistema vai correr mas também decorrentes do próprio tipo de aplicação) então o Java é uma boa opção, tão boa ou melhor quanto o C/C++ dado ser uma linguagem de mais alto nível (na verdade, as suas APIs).
    2. Se a aplicação tem um curto tempo de execução e a performance não é importante então o Java também pode ser uma boa opção mas temos outros "players" que podem até oferecer mais vantagens (Python, por exemplo).
    3. Se o tempo de execução é curto (ou a execução não é regular -- estava a esquecer-me deste pormenor) e a performance, ou o baixo consumo de memória, interessa então o Java perde claramente para o C/C++.
    O que acontece é que muitas aplicações do lado do servidor caem no primeiro caso e muitas aplicações desktop caem no terceiro (ficando as aplicações de business no meio) e é por isso que o Java é popular no servidor e impopular no desktop. Mas se eu acredito que o Java é uma boa solução no primeiro e segundo casos, tambem concordo que não o é no terceiro.

    -- Carlos Rodrigues
    Re:Choose your weapons (Pontos:1)
    por Perky_Goth em 21-03-04 19:51 GMT (#9)
    (Utilizador Info)
    em relação ao primeiro ponto, é de notar que um JIT pode fazer melhores optimizações por dispor de informações do programa em execução, coisa impossível em C/C++. pelo que ouço, há casos onde a velocidade é muito semelhante.
    ---
    Trolls, nem respondam porque não vos ouço.
    Que Bush vos abençoe.
    Re:Choose your weapons (Pontos:1)
    por Mojo_risin em 22-03-04 18:42 GMT (#10)
    (Utilizador Info)
    O C++ pode dispor de RTTI, ou seja, "run time information" o que lhe permite obter informações sobre o programa em runtime. Isto também possível através de meta-programação, se bem que o compilador não sabe bem o que está a fazer, porque não há suporte na própria linguagem (no caso do C++)... O Qt é um exemplo da utilização de meta-programação.

     

     

    [ Topo | Sugerir artigo | Artigos anteriores | Sondagens passadas | FAQ | Editores | Preferências | Contacto ]