meus colegas de trabalho, DANIEL e FELIPE falaram que eu sou burro e que java e jdbc num serve pra nada.
eh pra ser tudu feito em stored procedure que eh melhor e que empresa num troca de banco NUNCA, pq eu sou burro e acho q a empresa troca de banco q nem troca de roupa.
queria saber q opniao de vcs, pq nao concordo com isso. acho melhor a independencia de banco do q ficar amarrado ao mesmo.
ps: ELES QUEREM FAZER TUDO NO BANCO, ATÉ 1 + 1.
flw!
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
[quote=cv] solucao eh …
pra ajudar a manter as coisas num clima de familia e todo mundo trabalhar mais feliz
[/quote]
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).