Desculpe-me pela ignorância, mas… Você rodou Java no Oracle e ficou mais rápido do que no application server?
Por favor, me corrija se estiver errado!
Abraços!
O Oracle tem recursos para o código java. Inclusive tem um application Server da Oracle que é considerado o application server mais rápido do mercado.
[quote=“oazuc”][quote=“fabgp2001”]
O código que eu falei foi criar um java dentro do banco ( o Oracle aceita isso ) e com retornar o que meu SQL retornou, este retorno eu colequei num resultset ou seja conversei com o a parte web na lingua dele JAVA. Nada de código extra para o mesmo SQL.
[/quote]
Desculpe-me pela ignorância, mas… Você rodou Java no Oracle e ficou mais rápido do que no application server?
Por favor, me corrija se estiver errado!
Abraços![/quote]
Não…o que ficou mais rapido foi o SQL rodando no banco…mas para retornar ao Java os registros eu usei um java retonando um resultset.
[]'s
[quote=“Rafael Steil”]
Vendo de um outro ponto, se, ao inserir novas informacoes, voce precisa de informacoes de um outro lugar, e para fazer isso voce teria que consultar os seus objetos, popular eles, e entao passar o objeto bonitinho para a camada de persistencia, entao ja me parece melhor passar os dados basicos para a procedure, e ela entao pega os dados que faltam…
Rafael[/quote]
desculpe pela insistência, mas estes campos adicionais podem ser considerados regra de negócio também! Imagine que de uma hora para outra determinado dado como o número de celular que antes era pesquisado pela SP que insere a venda deixa de ser necessário para o negócio da empresa? É claro que é um exemplo bem trivial, mas poderia acontecer com registros mais complexos… Daí toca o pessoal da programação notificar o DBA para modificar as SP pra gente!
Até concordaria em deixar alguma coisa que acessa os dados e não é regra de negócio no banco… Só não consigo imaginar nenhuma situação desse tipo (é que já é sexta à tarde 
)
Meu Deus, o q seria de nós sem a ORACLE… gente, vamos rezar para ORACLE não quebrar!!! :agrue:
O maior problema que eu vejo com é a mentalidade que vem associada junto. Todo desenvolvedor que usa OO costuma ter asco ao modelo relacional e toda porcaria associada a ele.
Oque eu costumo ver com o pessoal que usa muita SP é estar com a cabeça ainda engeçada na droga do modelo relacional, alem de ser incapaz de dissociar persistencia com um RDBMS, não aceitando que fazer persistercia de dados em qualquer outro meio.
Dos casos onde ter uma SP supostamente deixa mais rápido, eu não conheço um onde o problema é o fato do modelo de dados mapear muito mal para o relacional; uma estrutura hierarquica é um ótimo exemplo disso, com varias pesquisas envolvendo muitos niveis via SQL a performance vai ser sempre uma droga pq vai envolver toneladas de join, enquanto que usando, por exemplo, um servidor de diretorios, tais pesquisas seriam triviais.
Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.
Olá
Amigos, desculpem-me o off tópic mas não posso deixar passar esta.
CV, apesar da mistura do “te” com "“você”, muito obrigado por este delicioso parágrafo:
Adorei a oportunidade de saborea-lo. Tecnologia com criatividade e inteligência. Já valeu minha vinda aqui hoje.
[]s
Luca
Opa, mas nesses casos voce sempre precisara do DBA… se tiver que alterar a tabela, quem ira fazer isso? se a empresa tiver um DBA, nao sera voce…
Esses casos de “ah, mas se isso um dia mudar”… entao, quando esse dia muda, voce vai la e muda, assim como tera que mudar as regras da tua aplicacao.
Veja pelo outro lado: voce faz tudo via objeto… entao alguem decide que determinadas tabelas nao sao mais necessarias, ou camps sao mudados/adicionados… nesse caso, o DBA tera que ir ate o programador e pedir para ele alterar.
Voce tera esse tipo de problema em qualquer das situacoes… Se quiser evitar, nao use banco de dados.
Rafael
Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.
Olá
CV, pelo preço que a gente paga ao DBA quando precisa de um aqui na empresa o cara instala o banco, cria a base, otimiza tudo e ainda limpa os banheiros.
[]s
Luca
Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.[/quote]
Ta certo, viajei grandao. Mas nesse caso entao nao sera ele que fara a procedure tmb. Troque “dba” por “carinha que cuida do banco do sistema”.
Rafael
Ah sim, aquele figurao mitico que de vez em quando tenta mover objetos por aih com a forca do pensamento, passa semanas frustrado por ainda nao ter conseguido, e desconta a raiva nos programadores. Geralmente o salario dele tah bem longe disso, mas por aqui a gente chama esse cara de “babysitter de oracle”, pq no fundo no fundo tudo o que ele faz eh isso. Tambem conhecido como Orasitter 
Ei, olhem! Eu tenho DOIS pirulitos!
oferece um para o cvpotter e outro para o steilar
:mrgreen:
[quote=“louds”]Oque eu costumo ver com o pessoal que usa muita SP é estar com a cabeça ainda engeçada na droga do modelo relacional, alem de ser incapaz de dissociar persistencia com um RDBMS, não aceitando que fazer persistercia de dados em qualquer outro meio.
Dos casos onde ter uma SP supostamente deixa mais rápido, eu não conheço um onde o problema é o fato do modelo de dados mapear muito mal para o relacional; uma estrutura hierarquica é um ótimo exemplo disso, com varias pesquisas envolvendo muitos niveis via SQL a performance vai ser sempre uma droga pq vai envolver toneladas de join, enquanto que usando, por exemplo, um servidor de diretorios, tais pesquisas seriam triviais.
Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.[/quote]
Louds,
A maior parte do meu tempo com info foi desenvolvendo com banco, mas tb usando java.
Apesar disso eu naum tenho esse pensamento que vc disse ai em cima, estudo outros metodos de armazenamento, bancos oo, persistencia em XML e tudo mais, mas tenho um pensamento realista. Ja que tocou neste ponto me diz ai como armazenar 70GB ou mais de info sem ser em um banco de dados relacional? Como montar um DW sem ser em um banco relacional? Existe essa solução hoje em dia?
[]'s
Pééééé. Resposta incorreta. Um DBA eh administrador, e nao engenheiro. Ele nao cria a base, ele a mantem funcinoando. Mesma diferenca entre um administrador e engenheiro de redes. Sao conhecimentos distintos. Se o DBA da sua empresa brinca de dublê de DBE, entao tem alguma coisa errada.[/quote]
Isso depende de cada empresa: se eh uma com um MIS pequeno, entao o DBA é o cara do banco, das procedures, no explorer, da rede…rs… Mas em empresas grandes, DBA só pra ADMINISTRAR mesmo!, Tipo, vc cria e manda o cara compilar; Retirar colunas é com o cara… etc…
Aew,
Me desculpa…mas quem nunca trabalhou com algum produto Oracle direta ou indiretamente? Se nunca fez isso provavelmente nunca trabalhou para uma grande empresa.
[]'s
E o ponto em que vc esta querendo chegar aqui eh…? Que a Oracle eh grande e tem uma penetracao no mercado enorme? Uh… legal, mas nao sei no que isso se encaixa na conversa
PS: cacete, como eu tou troglodita hoje. preciso tomah uns prozacs.
Em aplicações feitas sob medida para uma unica empresa…essas que elas pagam uma grana preta para desenvolver…o melhor é deixa no banco mesmo. Me diz ai qual empresa que troca de banco de dados? Eu perticularmente não conheco nenhuma.
Agora se vc vai desenvolver uma aplicação para vender…no banco só se for loco…
Sei que o pessoal do naum curte muito largar no banco os SQL, por causa de reusabilidade do código…isso até é uma verdade, mas que estando no banco é mais rapido isso sem duvida. Ainda mais se o baco for Oracle.
[]'s[/quote]
Affff queimei a lingua…
FUi falar que dificilmente uma empresa muda de banco e a propria que estou trabalhando me vem com essa noticia oh vida…
O pior de tudo, não adiantou nada deixar as regras de negocio fora do banco la no java tudo bunitinhu…vaum trocar a tecnologia tb…e imaginem pra qual??
arhhhh…estou orfão …acho que vou fazer as malas e tentar a sorte em outras bandas…
Ps.: Garanto que foi praga do CV…hiauhaiuhai zuera loco.
[]'s
[quote=“louds”]
Agora convercer um cara que usar um banco relacional é uma má idéia me parece mais dificil que fazer o cv gostar de stored procedures.[/quote]
Acho que o louds se referia à utilizar regras de negócio no bd e não “não utilizar bd relacional”. Se entendí errado me corrija louds…
[quote=“fabgp2001”]
Aew,
Me desculpa…mas quem nunca trabalhou com algum produto Oracle direta ou indiretamente? Se nunca fez isso provavelmente nunca trabalhou para uma grande empresa. [/quote]
Uhhhhh… essa doeu… mas brincar com ORACLE eu faço no meu desktop. Não estou desprezando a tecnologia não, eu sei muito bem a grande fatia que os caras tem no mercado… cá pra nós, vc acha que por trás das maiores instituições financeiras (pra não dizer todas) roda o quê??? ORACLE ou o produtinho de 3 letras da big blue?
E o ponto em que vc esta querendo chegar aqui eh…? Que a Oracle eh grande e tem uma penetracao no mercado enorme? Uh… legal, mas nao sei no que isso se encaixa na conversa
PS: cacete, como eu tou troglodita hoje. preciso tomah uns prozacs. :D[/quote]
Não não cv…eu so fiz um comentario a uma reposta la atras de um colega…onde ele diz o que seria de nós sem a Oracle…
Para mim representa muita coisa…até hoje so encontrei bancos oracle pela frente…
Agora vai chover pedradas hehehe…
Blz…mas entendo que naum esta no escopo do assunto…
[]'s