Java num serve pra nada

Cara, a idéia de independência de banco é real. O que existe é que a longo prazo a empresa pode estar migrando para outro banco, e então será necessário a reescrita destes códigos em storedprocedures/triggers em outro banco, correndo-se o risco de criar-se bugs etc.

Muitas vezes, o que acontece. Uma empresa trabalha com determinado banco de dados, e tudo esta tranquilo durante algum tempo, até que a empresa recebe uma proposta de outra empresa de banco de dados, e então os administradores, sem dó do desenvolvimento, dizem que será tudo em outro banco e ponto inal. Imagine o pandemonio neste cenário.

Outra característica interessante, é para empresas de desenvolvimento de software, onde determinados clientes podem estar querendo um determinado banco de dados, e outros clientes optarem por outras soluções. Então, a idéia de independência de banco é muito válida.

A questão de eles te otularem de buro ou qualquer outo adjetivo, é o fato de não terem argumentos favoráveis a eles, e estão tentando te desestailizar psicológicamente. Se você tem argumentos para desbancar a proposta deles, vá em frente, se não der certo, e lá na frente tiverem que reescrever tudo em semanas (ou dias), não diga que você não avisou.

Ainda poderia-se citar vários outros cenários possíveis de onde não depender-se primordialmente de banco de dados seriam plaus´iveis, e outro ponto é a dependência do SQL proprietário. Tente usar SQL padrão, ou um framework de mapeamento ou algo do gênero, como Hibernate e JDO.

[]'s

Sobre ser chamado de burro, a solucao eh garrafa de vidro quebrada na quina da mesa e enfiada na jugular deles, preferencialmente dentro do ambiente de trabalho, pra ajudar a manter as coisas num clima de familia e todo mundo trabalhar mais feliz. Nao se esqueca de subir na mesa e berrar bastante pra todo mundo ver, ja que ficar de fora de um acontecimento desses seria uma pena.

Quanto ao resto, se a independencia de banco nao eh uma prioridade no projeto, otimo, da pra usar os recursos e a performance que as stored procedures trazem para algumas coisas. Para algumas coisas. Voces precisam sempre levar em conta o tempo que os dados passam boiando pela na rede local ou entre os processos do banco e da aplicacao.

Na minha opniao , o java é uma otima linguagem …

acho que tudo dever ser avaliado …

participei de um projeto onde tudo foi feito em PLSQL/Oracle e o java chamava as packages.procedure … não vi nenhum problema neste modelo …

participei de outro que parte ficava no java e outra no PLSQL/Oracle … tambem não vi problemas neste modelo … pois alguns processos mais criticos ficaram no banco.

Ou seja independente do modelo adotado … o java terá sua partipação !!!
isso e o mais importante …

Como o cv disse, se a independencia de banco nao eh algo desejado pela empresa, tem mais eh que tirar proveito dos recursos oferecidos pelo dbms. Claro que isso nao significa radicalizar.
Assim como o banco de dados pode ser mudado no futuro, a linguagem de programacao tambem pode mudar do dia para a noite, por causa de “decisoes gerenciais”, entao, a grosso modo, voce meio que troca 6 por meia-duzia.

Parece ai que vc esta em desvantagem frente ao pessoal que defende banco de dados com todas as forcas. Nesse caso, voce pode fazer vsta-grossa e aderir a forma de trabalho deles, ou procurar outra empresa ;).

Rafael

e ainda tem a outra discusao sobre isso…

http://www.guj.com.br/posts/list/0/8443.java

cv:

solucao eh …
pra ajudar a manter as coisas num clima de familia e todo mundo trabalhar mais feliz

o cv da cada resposta

eu concordo de que a empresa não muda de banco a todo momento…

mas com store procedures você fica meio “amarrado”… tipo vc não tem todo um poder que teria numa linguagem de programação como java…

e usar store procedure justifica-se apenas se o seu cliente de “obriga” ou se performance é o requisito primário… e ainda mesmo no caso de performance em 90% dos casos vc não vai precisar disso…

eu tava pensando em dizer isso mas nao sabia se seria politicamente correto :mrgreen:

Se a conversa está nesse pé é melhor mandar o curriculo pra outro canto, qualquer argumento não valerá nada …

usarei da tecnica do CV. garrafa eh uma boa ideia, mas sao 2 pessoas e eu vou ter q escolher uma, entao eu pensei em jogar alcool e tacar fogo, assim acerto os 2 de uma vez.

acordei revoltado hj, ahwahwha

se algum dia tiver q mudar de banco, manda-los-ei a mierda

flws!

WNS ,

se no futuro alguem pedir para mudar de banco ...
 você dirá assim :

          pois não , estou aqui para atende-los .... 


  obs: quanto mais eles mudam mais trabalho teremos mais java teremos ...

Emrpesas não mudam de banco de dados todos os dias. A maioria dos sistemas vai fciar defasando antes de ter oportundiade de mudar de banco. Agora…

por que diabos as pessoas acham que podem confiar num treco feito apra guardar dados como um servidor de aplicações?

Aì vem pergutnas bizarras no fórum sobre como fazer uma Stored Procedure enviar respsotas HTTP ou abrir um socket… cada ferramenta tem seu uso! Aposto que eles acham que o sistema operacional também devia ser todo em SP.

No início eu achava que independência de database era a principal característica de o-r mapping. Depois que iniciei com hibernate classifico independência de banco de dados um benefício secundário diante das centenas de vantagens de somente lidar com objetos invés da porqueira de sql e outras coisas que não preciso me preocupar sendo que o framework faz a maior parte do trabalho sujo.

hahahahaha
Eu tbm acho qeu Java não serve pra nada =/
não da pra fazer quase nada com ele… ta loko… =)~

Quem aqui sabe de uma empresa que tem Oracle e mudou de banco depois?!
hehehehe
Os caras ai mandaram fazer tudo em StoreProcedures?! hehehe
aqui na empresa eh diferente, (burrice um pouco) os “Donos do Oracle” proibiram usar SP hahahaha vai entender… vc tem uma Ferrari mas num pode passar de 40Km/h …

Mas se seu cliente tem uma licensa de SQLServer, bom, dai eu garanto qeu se vc usar Hibernate não vai se arrepender depois por ter usado, pq com certeza ele vai mudar de banco… ainda mais se tu não ganhar a mais para fazer essa migração.

=)

Abraços!

Java serve para, pelo menos, discutirmos a utilidade dele. Já é alguma coisa, né? :mrgreen:

O cara te chamar de burro pq ele quer colocar a regra no banco e vc em classes java. Em que mundo ele vive? Ele acha que java é só para escrever GUI?

OBS: Gostei da solução do cv para isso!!

Aqui no trabalho onde existe uma consulta muito pesada e que envolva muitas unions, joins etc, que esteja consumindo muitos segundos (existe um tempo limite para que os usuários do sistema realizem as operações), colocamos uma procedure (depois de tentar outras soluções) para retornar o resultado da consulta. mas na regra do negócio propriamente dita evitamos as procedures .

Aqui na empresa acho pouco provavel mudar o banco (e se for mudar vai dar um trabalhinho graças as procedures existentes) ja que todos os sistemas que eu tenho conhecimento estão rodando em cima do Oracle.

Se vc esta desenvolvendo uma aplicação para clientes e ambientes diferentes, ligar sua aplicação a um banco, servidor de aplicação ou sistema operacional não é uma boa idéia.

Na minha opiniao voce deve preparar uma lista com centenas de argumentos e vantagens da sua abordagem, elaborar um discurso bem convincente e levar tudo isso para quem vai tomar as decisoes - porque esse negocio de “eu quero isso, meu colega quer aquilo” nao resolve nada. Quem vai decidir ouve as partes, decide e que se dane. Pra isso que existe o conceito de lider (ou capataz, em boa parte dos casos).

Se a opcao for priorizar SGBD, fazer o que - nem sempre as qualidades tecnicas que achamos serem as melhores vencem. Claro, nesse caso guarde sua listinha de argumentos na gaveta e prepare frases de efeito para que ao sinal do primeiro problema na abordagem escolhida voce possa subir na mesa e gritar: “A-ha! Eu disse eu disse eu disse! Bem que eu avisei!” - e coisas simpaticas do genero. :mrgreen:

Marcio Kuchma

… ou ainda “Capitão do Mato”!

Meu problema com stored procedores é a manutenção. Acho um saco escrever e debugar stored procedures. Escrever e debugar código java é tão mais fácil e prazeroso… tudo bonitinho, orientado a objetos, vc alterar sem preocupação…

Sem contar na hora de fazer alterações no sistema vc nunca sabe onde as stored procedures são chamadas, então vc altera alguma coisa vai dar pau num lugar que vc nem sonhava que ela era usada.

E quando tem um DBA cuidando do banco ele sempre enche o saco na hora de alterar as procedures…

[]'s

hum. stores procedures não deveriam ter sido banidas com a arquitetura cliente-servidor?

Um não viabilia o outro, pelo contrário. C/S tradicinal se beneficia de SPs para manter a lógica centralizada, o que num ambiente n-tier tem sua própria camada(s).

Um não viabilia o outro, pelo contrário. C/S tradicinal se beneficia de SPs para manter a lógica centralizada, o que num ambiente n-tier tem sua própria camada(s).

formulei minha frase errada
stores procedures não deveriam ter sido banidas junto com a decadente arquitetura cliente-servidor?

Rubem, isso tudo demonstra que vc nunca mexeu de verdade com banco de dados.

Rafael

Eu estou numa grande empresa (líder de mercado) que usa banco Oracle. Eles NUNCA vão mudar de banco, a não ser que queiram vender todo o patrimônio para pagar as consultorias com as alterações necessárias.

Alguns projetos usam stored procedures, outras não. Boiolagem ou frescura da decisão dos DBAs. Então não temos um apadrão firme quanto a isso aqui.

Neste caso é válido jogar muitas coisas nas SPs e deixar o Java só como casca.

Agora, se você procura desenvolver aplicações mais genéricas e diversificadas, que atendam a mais de uma empresa, então a independência de BD é importante.

Acho importante mencionar que “independencia de db”, qdo nao bem compreendido, pode ser catastrofico tambem. O meu entendimento disso eh que voce deve ter uma maneira relativamente facil de usar o banco X ou Y sem ter que alterar o core do teu sistema.
Ou seja, usar uma camada de abstracao bem feita, o que te permite fazer o que quiser e como quiser com o banco, desde que os dados venham conforme o solicitado.

Rafael

E o que vc sugere??? :mrgreen:

:arrow: Aeh, WNS, compra um mutchaco (escreve assim?). Vai ser moooito mais divertido no caso de um combate… hehehehehe

Sua sign serviu pra mim nesse momento, hehehhe.

O problema meu com as stored procedures eh q o sistema nao eh soh pra um cliente. eu queria usar hibernate, mas…

vlw!!!

Deve-se observar o tipo de produto, eu trabalhava em uma empresa que tinha um produto que quando foi desenvolvido para o Cliente A foi utilizado SQL Server, dai o cliente B comprou o produto e queria usar com o Oracle qeu ele já tinha, e um terceiro pedio para que usassemos (argh) Intebase… Imagine se estivessemos utilizando SP !!! Estariamos ferrados. Esse eh um caso que nuam se deve usar SP nem nada muito especifico do banco.

So para completar, o sistema roda em varios clientes com 3 bancos de dados diferentes, o sofware eh o mesmo, apenas com uma mudança de uma linha em um arquivo de configuração.

[]´s

No meu ponto de vista isso depende de dois fatores antes de comercarmos a discutir.

1 - O Software desenvolvido será criado somente para um cliente?
2 - Não, o Software faz parte da carteira de produtos de uma SW House.

Se 1 verdadeira, a probabilidade do cliente querer utilizar os recursos do banco é imensa., por varios motivos.

1.1 - Ele tem um p*** servidor de banco e não quer disperdicar recurso.
1.2 - Os vendedores do banco foram la e enfiaram na cabeca de quem manda que isso é a melhor saida.
1.3 - A equipe é velha de guerra em SP e trocar tudo numa tacada só teria uma perda de tempo nao aceitavel pelos custos, restricoes de mentalidade.
1.4 - …

Se 1 falsa e 2 Verddeira.

2.1 A sobrevivencia desse produto depende deste recurso e era isso.

]['s

Rafael Steil:

Rubem, isso tudo demonstra que vc nunca mexeu de verdade com banco de dados.

Rafael

como o pessoal presume facil as coisas sem saber da real situação…

Presumindo ou nao, acertaram :mrgreen:

Cara, pega mais leve nos posts. Voce ta causando.

cv:

Presumindo ou nao, acertaram :mrgreen:

Cara, pega mais leve nos posts. Voce ta causando.

sim, vc me conheçe pessoalmente, eu havia me esquecido… sabe exatamente tudo que eu sei…

aliás, vc deve até ter lido minha mente…

calma la pessoal. sem mensagens de uma linha sem pensar, a gente tem um historico de menos de uma mao de topicos fechados.

Independencia de banco é muito útil na hora de escrever testes funcionais e de integração.

Se tua aplicação funciona com HSQL e Oracle, muito melhor executar os testes contra um banco em memoria.

louds:

Independencia de banco é muito útil na hora de escrever testes funcionais e de integração.

Se tua aplicação funciona com HSQL e Oracle, muito melhor executar os testes contra um banco em memoria.

Dependendo do caso o mesmo vale para o desenvolvimento tambem. Ter um banquinho leve na tua maquina sem depender da rede ou do servidor eh otimo na hora do desenvolvimento dia-a-dia.

Marcio Kuchma

louds:

Independencia de banco é muito útil na hora de escrever testes funcionais e de integração.

Se tua aplicação funciona com HSQL e Oracle, muito melhor executar os testes contra um banco em memoria.

Ótimo argumento, aliás, uma historinha que aidna que não seja sobre SGBDs, é sobre isolar o acesso à recursos:

Trabalhei num sistema que gerencia um grande serviço em tempo real. Este sistema possui uns conectores para o serviço, mas este serviço roda numa máquina DEC ALPHA com Tru64. Temos algumas máquinas dessas aqui, mas não dá para cada um ter uma cópia do serviço rodando.

Tentei simular o serviço, abrindo um socket em outra máquina e tentando mandar respostas falsas e testar apenas a minha parte do sistema e… nada. Não dá, a parte Java é extremamente acoplada com a outra, meu mock teria que ser uma cópia perfeita do sistema original. Resolvi pegar mais pesado então: substituir o conector por um mock. Também não dá. O código está espalhado em milhares de lugares diferentes, o conector em si não serve para quase nada.

No final das contas eu tinha que sair na porrada para conseguir um serviço para testar, e muitas vezes tinha que agendar testes para a noite, quando a máquina estava vazia. Issoporque alguém achou realmente que este negócio de camadas, independência, separação de responsabildiades, etc. era besteira. Que devia fazer tudo acoplado, já uqe o serviço em questão iria prover tudo que era preciso…

banir StorProcedures?!
ta maluco?!

é isso q eu to querendo saber

lógico qeu não…
StoreProcedures são e vão continuar sendo muito úteis…

Acho que vc está se confundindo com alguma coisa!

abraços!

jujo:

lógico qeu não…
StoreProcedures são e vão continuar sendo muito úteis…

Acho que vc está se confundindo com alguma coisa!

abraços!

O único problema que consigo enxergar com SP além da dependencia de banco, é o custo de desenvolvimento, á mais trabalhoso e cansativo desenvolver em SP, na minha opinião claro, tem gente que gosta.

Existem sistemas com acesso a dados por chamadas de procedures, pois levam em conta a otimização no plano de execução que um banco usa na SP, sinceramente não sei mensurar vantagem disso em contra um Mapeamento O/R.

Quanto à dependencia de uma determinado fabricante de banco de dados, cada cabeça um guia, eu particularmente não vejo motivo pra se esbaldar de recursos proprietarios de determinados bancos de dados. Por mais que vc ache que não, algum dia vai aparecer uma necessidade de seu sistema migrar de base de dados.

E outra se a plataforma de desenvolvimento distribuída é tão difundida, não é por acaso, é só pesquisar as vantagens de um sistema distribuido, o que de benefício se ganha em se desacoplar as camadas de teu sistema:

no tradicional modelo distribuido: Presentation Layer <–> Business Layer <–> Data Layer

Cada camada tem um papel distinto dentro de um sistema distribuido, e executa esse papel da melhor maneira a que é destinado.

“trabalhoso e cansativo” eh mais uma coisa pessoal que uma generalizacao. Dependendo a tarefa que vc quer fazer, pode ser muito mais simples usar a linguagem de scripts do banco que uma outra linguagem de programacao mais alto nivel.

Sobre o ponto do louds referente testabilidade, isso eh mais facil de conseguir se voce usar um framework de persistencia que funcione direito, como o Hibernate, caso contrario da um bom trabalho “generalizar”, ja que voce tem que lidar com sintaxes diferentes para diferentes bancos de dados. Ou seja, voce faz o sistema usando mysql, mas ao testar coloca um hsqldb no lugar. Nessa brincadeira vc pode acabar tendo uns problemas com as queries, e ai entra um outro que comentei antes, que eh ter uma maneira “simples” de lidar com isso.
No JForum eu consigo fazer “override” de queries, o que me permite ter um arquivo .sql gigante com todas as queries, e um outro .sql bem minusculo com as queries proprietarias de cada banco, caso necessario ( e isso soh costuma ocorrer em INSERTs que precisam retornar a key gerada e controle de paginacao de resultados. )

Rafael

isac:

WNS ,

se no futuro alguem pedir para mudar de banco ...
 você dirá assim :

          pois não , estou aqui para atende-los .... 


  obs: quanto mais eles mudam mais trabalho teremos mais java teremos ...

Vc ta certo, quanto mais,
melhor… hehehehe

E a ideia do CV nao podia ser pior,
ops, digo melhor…
Junta a ideia do CV com a sua,
assim os caras nao escapão mesmo…

E burro são eles, por pensarem de tal forma…

Ana.

Mas vale lembrar que ferramentas como Hibernate não são a salvação para se conseguir independencia de fonte de dados e facilidade de desenvolvimento.

Uma vez migrei uma aplicação que usava hibernate de mysql p/ sqlserver, tive 1 penca de problemas para resolver devido a forma de cada banco trabalhar com transações, locking e outros detalhes.

Não esperem que seja apenas uma questão de mudar o hibernate.properties que tá pronto pra outro banco, isso é uma mentira.

Modularidade é a chave.
A capacidade de replicar ambientes, separar componentes, substituir peças são os pontos mais pertinentes desta discussão.

(já que aqui no Brasil o desenvolver tem que se virar e fazer papel de analista, arquiteto e programador, acho sine qua non o pessoal dar uma lida em livrinhos de arquitetura mesmo sem ter a pretenção de tirar a certificação)

É completamente diferente retirar componentes java e substituir por outra linguagem (.NET, por exemplo), que migrar banco de dados todo amarrado em sp.

“Não gostou da solução em java, joga fora a porcaria e coloca outra coisa ali que implementa a mesma idl ou wdsl”.

Não que store procedures sejam coisas ruins. O problema é o ambiente amarrado e preso… irretorquível.

Muitas coisas podem acontecer na vida de uma aplicação que explica a preocupação com o longo prazo. Mudança do banco de dados, mudança no modelo da aplicação,Outsourcing.

Enfim, acho que uma store procedure tem um alto custo em manutenção…
É pesar isto com a vantagens que ela pode oferecer.

Eles estao com ciumes de vc, pois vc esta trabalhando com uma linguagem excelente, robusta, orientada a objetos, 100% portavel, focada para integraçao e internet, que paga salarios muito melhores , que tem uma comunidade unida e que se ajuda…

Entretanto, usar ou nao SP e uma decisao de arquitetura e diretriz tecnologica, nao somente de desenvolvedor ou dba xiita…

Morte aos DBAs pois eles nao fazem o que deveriam fazer, que e dar suporte ao desenvolvedor ao inves de ficar criticando-os…

Se realmente isso der problemas no futuro então você vai virar estrela Se você realmente acredita, documente sua posição pra esfregar na cara deles depois

O renato3110 falou tudo agora… já pode até fechar o tópico!

É WNS, você tá em minoria… deixa rolar, documenta e mostra pra eles o desgaste que será depois…