Oracle desiste do projeto Kenai

Assuntos Gerais Notícias
#21

Puxa vida, é uma pena, se bem que eu não conhecia direito o Projeto, apenas assistí uma aula da Faculdade que meu professor comentou sobre.
Só espero que a Oracle não faça da Sun uma empresa proprietária. Aliás, um dos melhores SGBD é dela, o que possivelmente tornará o MySQL muito melhor do que é hoje, é um ótimo banco da Web, porém para aplicação de grande porte não é indicado.

#22

jEder, Oracle não é o melhor banco de dados não. Há muitos bancos relacionais bons por aí do mesmo porte que o Oracle, e porque não até melhor? Trabalho com Oracle há aprox 12 anos, e obvio que é bom, mas ele tem muito mais nome e fama do que realmente é.

MySQL já não dá para dizer que é apenas para projetos pequenos. Desde a família 5 o MySQL tem muitas funcionalidades dos maiores bancos como procedures e jobs. Obviamente muitas dessas funcionalidades foram feitas meio encima da hora e não são tão completas, porém havia muito o que crescer no MySQL. Em um projeto que trabalhei o MySQL executava 1.500.000 consultas por dia sem degradar performance. Ou seja, um banco com um bom futuro diante dos grandes que temos por aí.

Mas quanto ao Kenai, isso não me surpreendeu. Embora não sabemos ao certo o que será do futuro dos filhotes da Sun, a coisa nunca mais será a mesma. A Sun sempre pensou muito mais em inovar do que lucrar, e duvído que a Oracle faça algo assim. Minha torcida é que mantenham os grandes projetos como Glassfish e Netbeans, e que evoluam cada vez mais. Além disso espero ver também o crescimento de projetos que eu tinha uma afinidade como Sun Spot e FX.

Em uma série de eventos que já participei da Sun fiz vários contatos, e conversando com esse pessoal o clima não está lá tão bom. Não estou dizendo que o futuro será maligno, porém essa incerteza toda causa um grande desconforto no pessoal da Sun.

#23

Se são muitos, não seria demais eu pedir uns 5, 6 exemplos só pra começar, por favor?

#24

Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O

#25

Se são muitos, não seria demais eu pedir uns 5, 6 exemplos só pra começar, por favor?[/quote]

Se você fosse um pouco mais educado e não viesse querendo fazer confusão eu responderia sem problemas. Mas já que é assim… procure no google.

#26

E o e-mail já chegou:

#27

[quote=jEder]Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O[/quote]

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

(Acho que o DB4O é um banco OO e não o banco relacional).

1,5 Milhões de transações por dia é muito pouco, pense quantas torpedos são enviados em um dia? e quantas ligações? quantas transações bancárias?

#28

[quote=evandro.santos][quote=jEder]Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O[/quote]

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

[/quote]

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.

#29

[quote=Ramon.Onix]A grande margem disso tudo só pode ser visando Lucro.
Tudo da ORaCLe é pago é igual Windows![/quote]

Qualquer empresa visa o lucro máximo, inclusive a Sun, não se engane achando que eles eram mais “bonzinhos” do que a Oracle. Só que a Sun não foi competente nisso, tanto que estava mal e foi vendida.

#30

[quote=Felagund][quote=evandro.santos][quote=jEder]Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O[/quote]

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

[/quote]

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.[/quote]

Desculpe, escrevi errado, Já trabalhei com Postgres, Oracle e Firebird.

Em minha experiência com o Postgres utilizava um banco bastante grande e o processo de Vacuum era sofrível, com a evolução do banco, foi adicionado a funcionalidade de particionamento, dessa forma passei a excluir a partição (não precisava de VACUUM), porem particionamento consumia muito processado.
Outro problema era adicionar JOBs, como o recurso era novo, as vezes tinha alguns problemas.

Hoje ainda utilizo Postgres em meus projetos pessoais, mas nenhum deles chega ao pico de 100 transações em um segundo. Não arriscaria colocar o postgres em uma situação como essa…

#31

[quote=evandro.santos][quote=Felagund][quote=evandro.santos][quote=jEder]Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O[/quote]

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

[/quote]

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.[/quote]

Desculpe, escrevi errado, Já trabalhei com Postgres, Oracle e Firebird.

Em minha experiência com o Postgres utilizava um banco bastante grande e o processo de Vacuum era sofrível, com a evolução do banco, foi adicionado a funcionalidade de particionamento, dessa forma passei a excluir a partição (não precisava de VACUUM), porem particionamento consumia muito processado.
Outro problema era adicionar JOBs, como o recurso era novo, as vezes tinha alguns problemas.

Hoje ainda utilizo Postgres em meus projetos pessoais, mas nenhum deles chega ao pico de 100 transações em um segundo. Não arriscaria colocar o postgres em uma situação como essa… [/quote]

Utilizamos bastante o postgre em sistemas concorrentes com varias transações simultaneas, e em alguns casos ele se sai melhor que o oracle, temos 2 sistemas com a mesma arquitetura, porém um roda usando Oracle e o outro Postgre, e te garanto que a performance do que roda postgre é superior, pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile :slight_smile:

#32

[quote=Felagund]
… pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile :)[/quote]

Isso porque quando você faz uma consulta por JPA o framework gera um comando SQL e executa do banco de dados. Se esse SQL for construído da maneira mais eficiente que o banco reconhece, beleza. Se não for, vai perder performance.

O Oracle permite algumas construções “sinistras” que permite gerar consultas enxutas e de alta performance, talvez a implementação NO SEU CASO não conseguiu extrair isso.

Claro, que hoje é praticamente consenso que é preferível ocasionalmente perder um pouco de performance na aplicação mas mante-la independente de banco, mas isso é outra discussão “acalourada”.

No nosso caso, tínhamos um banco postgres no nosso Call Center (uns 600 atendentes) e o número de consultas era muit o grande, muitas delas complexas e pesadas. Chegou a um ponto de que tínhamos de escolher se faríamos um upgrade do hardware do servidor ou passaríamos para Oracle ou Sybase. Fazendo testes, vimos que o upgrade de banco sairia bem mais barato.

#33

Ah, não usávamos JPA na época. Talvez se estivesse usando, o Posgres aguentaria, já que muita carga iria para o servidor de aplicação

#34

[quote=Felagund][quote=evandro.santos][quote=Felagund][quote=evandro.santos][quote=jEder]Bancos que eu conheço:

PostgresSQL;
Firebird/Interbase;
MySQL;
DB4O[/quote]

Cara, desses quatro só trabalhei com o Oracle e Firebird, mas uma coisa eu posso afirmar nenhum desses bancos se comparam ao Oracle.

[/quote]

No dia que vc brinca com o Postgre vc vai ver q o oracle não é tão bom assim não, e firebird? Firebird é horrivel.[/quote]

Desculpe, escrevi errado, Já trabalhei com Postgres, Oracle e Firebird.

Em minha experiência com o Postgres utilizava um banco bastante grande e o processo de Vacuum era sofrível, com a evolução do banco, foi adicionado a funcionalidade de particionamento, dessa forma passei a excluir a partição (não precisava de VACUUM), porem particionamento consumia muito processado.
Outro problema era adicionar JOBs, como o recurso era novo, as vezes tinha alguns problemas.

Hoje ainda utilizo Postgres em meus projetos pessoais, mas nenhum deles chega ao pico de 100 transações em um segundo. Não arriscaria colocar o postgres em uma situação como essa… [/quote]

Utilizamos bastante o postgre em sistemas concorrentes com varias transações simultaneas, e em alguns casos ele se sai melhor que o oracle, temos 2 sistemas com a mesma arquitetura, porém um roda usando Oracle e o outro Postgre, e te garanto que a performance do que roda postgre é superior, pode ser o uso do JPA, quem sabe em transações gerenciadas usando JDBC o oracle seja mais rapido, mas no caso do JPA o Postgre da um baile :)[/quote]

Concordo com você com relação a esse tipo de performance, o Oracle tem algumas particularidades estranhas. Se você faz uma consulta, onde um dos paramentos é a data, e você utiliza o default (passar um objeto Timestamp) o Oracle tem uma performance horrível, nesse caso ele tem que usar o terrível to_date(‘formato’, ‘data em string’), resumindo a performance atrapalha na portabilidade.

Espero que o toplink tenha otimizações para o Oracle…

#35

Vou odiar a Oracle pro resto da vida agora que vão cancelar o kenai, tinha vários projetos lá…

vou ter que transferir tudo pro google code agora… que trabalheira que essa oracle dá… :lol:

acho que vou até fazer uma cópia do código-fonte do netbeans, pena que não temos o do kenai… :shock:

#36

Em que parte eu não fui educado? Pedi que por favor, você citasse exemplos já que a sua própria afirmação dizia serem muitos. E você não quis responder ou não foi capaz, e tentou confundir, dizendo que eu estava fazendo confusão. Pra cima de mim com essa não.

#37

[quote=marcos.junqueira]Vou odiar a Oracle pro resto da vida agora que vão cancelar o kenai, tinha vários projetos lá…

vou ter que transferir tudo pro google code agora… que trabalheira que essa oracle dá… :lol:

acho que vou até fazer uma cópia do código-fonte do netbeans, pena que não temos o do kenai… :shock: [/quote]

Eu bem que queria o kenai pra instalar na intranet daqui da empresa. A gente na verdade quer é um forge com as ferramentas de comunicação que o netbeans tinha com o kenai.

#38

Eu não usava o Kenai, mas qual era a funcionalidade dele? Apenas de repositório e colaboração ou também poderia executar os códigos semelhante ao GAE?

Ps: A conversa anda bem quente no post sobre o fim do Kenai: http://blogs.sun.com/projectkenai/entry/the_future_of_kenai_com

#39

É um bom projeto, só acho que não estavam dando a devida atenção.

#40

Pessoal,

Como eu já havia comentado, não vão desistir do Kenai. Vejam a notícia completa:
http://blogs.sun.com/projectkenai/entry/the_future_of_kenai_com

". We don’t believe it makes sense to continue investing in multiple hosted development sites that are basically doing the same thing. Our plan is to shut down kenai.com and focus our efforts on java.net as the hosted development community. We are in the process of migrating java.net to the kenai technology."

[]s
Yara
http://twitter.com/yarasenger
http://blog.globalcode.com.br
http://www.eletronlivre.com.br