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).[/quote]
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
[quote=Rafael Steil]Rubem, isso tudo demonstra que vc nunca mexeu de verdade com banco de dados.
Rafael[/quote]
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.
[quote=cv]Presumindo ou nao, acertaram :mrgreen:
Cara, pega mais leve nos posts. Voce ta causando.[/quote]
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.
[quote=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.[/quote]
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
[quote=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.[/quote]
Ó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!
[quote=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![/quote]
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