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[/quote]
Claro que existe essa solução hoje! Bancos OOs são uma realidade e alternativa viavel a banco relacionais, já lí casos de sucesso com bases gigantescas e performance muito boa.
Servidores de diretorio, LDAP, são outro caso. Existem deployments com diretorios na ordem de 1 tera, a CNN é um bom exemplo disso. Os requisitos de performance não seriam possiveis usando ums RDBMS.
Eles usam NDS para fazer autenticação, autorização e personalização. São 2000 queries por segundo, com tempo de resposta inferior a 250ms, em um diretorio com milhões de objetos.
Eles usam NDS para fazer autenticação, autorização e personalização. São 2000 queries por segundo, com tempo de resposta inferior a 250ms, em um diretorio com milhões de objetos.[/quote]
Eu tenho uma curiosidade muito grande com relação ao Google. Você tem esses dados deles??? Quantas querys por segundo, tempo de resposta. E fugindo um pouco de assunto, é verdade que o sistema deles é feito em python ?
quando vcs fazem um sistema p/ o cliente vcs naum projetam o BD tb???
eh muito mais produtivo a programcao em SQL…qnto mais vc puder programar no banco melhor, o processamento do banco eh muito mais rapido q o da aplicacao
c o DBA nao pode fazer nenhuma alteracao (criar o banco) no banco intaum qem vai fazer isso? fazer alteracoes no banco quando necessario (por exemplo mudar uma procedure, criar o banco) nao eh dar manutencao???
otra coisa: SGBD d verdade eh firebird e postgree
oracle soh no caso d aplicacao ser muito muito grande, pq ele eh caro pra burro
Programar em SQL não é lá muito produtivo. Talvez você esteja falando de facilidades especiais embutidas em alguns SGDB.
Quanto menos você programar no banco melhor pois sua aplicação fica independente do banco.
O processamento no banco pode ser mais rápido mas na prática raramente isto acontece. Na maioria das vezes quem programa as stored procedures não é um DBA especializado em performance tunning. Então na maioria das vezes elas NÃO são mais rápidas a ponto de justificar tirar o controle de acesso ao banco dos programadores Java que podem usar frameworks razoavelmente produtivos.
O uso de stored procedures só se justifica quando se quer isolar regras de negócio dos programadores para evitar vazamentos em caso de saída de programadores da equipe. Por desempenho só vejo utilidade em raros casos de empresas que tem DBAs muito especiais.
Algumas vezes é interessante usar SP quando vc quer jogar um
pouco de lógica de programação na mão de quem não sabe Java.
É muito comum nas empresas com Oracle, os programadores só
conhecerem PL/SQL, e terem uma grande facilidade para criar
triggers,functions e SP.
Em alguns casos por facilidade e performance é interessante
dividir a lógica com o banco de dados.
Teve um cliente que não me passou nenhum SQL, simplesmente
mandava a equipe dele criar uma procedure que me voltava
um REF CURSOR e daí eu buscava os dados.
pra q uma plicacao independente d banco??? quando vc faz um sitema vc projeta o banco junto…agora c ainda assim vc qer q sua aplicacao sirva pra varios tipos d BD, coloque suas sql e suas rotinas d conexao num properties
ta loko… parece q vcs num conhecem nada sobre banco d dados, acham q todos os bancos sao q nem akelas porcarias d access e paradox da vida, q nem SGBD sao…
como o boaglio falou, deve-se dividir um pouco da logica do teu sistema com o banco… 8)
boaglio, obrigado pelas dicas, mas dê uma olhada na data da minha postagem hehe
lich king, na época que estava com essa dúvida, o argumento final para não usarmos stored procedures no sql server foi: se o cliente tiver Oracle, o que falo para ele? “Sinto muito, compre um sql server ou espere 3 meses para refazermos a aplicação toda”. Então preferimos escrever as regras de negócio em Java.
Não sei de qual linguagem de programação está vindo, mas claramente não está percebendo o poder que Java empresta ao desenvolvedor. Meu conselho é: utilize esse poder.
E outra, com essa arrogância toda, para quê você ainda pergunta, se está tão certo de seu conhecimento? Sempre ouvi, principalmente no começo, atentamente aos conselhos de pessoas como o Luca, que tem experiência sobrando e fazem a gentileza de ajudar nós, com tantas dúvidas. Não custa nada abrir um pouco a mente para esse mundo novo que está começando a explorar.
Calma, calma… Não é bem assim, pense no seguinte, supomos q eu coloque parte das minha regras de negócio em stored procedures… Se eu utilizar bancos diferentes como Firebird, Oracle e outros; terei que reescrever o meu código para cada um desses bancos (afinal a linguagem das stored mudam de bd para bd)… Isso com certeza pode ser um grande problema… Vc possui seu sistema pronto para 4 bancos de dados e derepente muda uma regra já implementada… lá vai vc alterar as stored dos 4 bd, ufa, não, muito obrigado!!!
Hoje em dia é bastante normal necessitar de independência de bd, já pensou vc chegar no seu cliente que gastou muita grana em um bd Oracle e dizer pra ele que seu sistema foi feito para o db2 e que ele terá que gastar mais alguns Reais (alguns???)… Acho que ele vai preferir procurar outra software house…
O Boaglio lembrou muito bem do caso especial de empresa que tem mais gente que conheça a linguagem do bando do que programador Java. Eu particularmente nunca vi isto, pelo menos programadores ótimos na base de dados.
Quanto a independência da base de dados quero lembrar que isto é uma vantagem imensa tanto na fase de desenvolvimento como na homolagação e futuramente na produção. Para aqueles que desenvolvem software com potencial de revenda isto passa a ser um requisito muito importante.
Escolher a base de dados no projeto da aplicação é muito bom porque as vezes os requisitos de projeto exigem bases paralelas e de muita capacidade e nestes casos os fornecedores são poucos. Mas minha opinião não foi para os casos especiais de uso de teradata ou oracle paralelo. Falei do caso comum do tipo que tenho aqui com um monte de stored procedures mal escritas, mal documentadas e sem avaliação de stress.
Esse ai ta parecendo eu quando cheguei por aqui, queria tudo dentro do banco. :lol:
Se voce entendesse tanto de banco assim nao falaria uma besteira dessa.
Vai reinventar a roda guardar em properties depois ficar lendo eles e criando sql dinamico? Argh se o DBA te ve fazendo isso.
Bom, experiência pessoal. Na empresa que trabalho, o uso de stored procedures é enorme, São cerca de 1500 stored procedures, grande parte delas com mais de 500 linhas. Banco Sybase e a empresa deu curso de performance tunning para todos os funcionários, sendo que contamos com 2 DBA’s e uma equipe de uns 10 programadores SQL. SIm, equipe especializada. Mas o Sybase não está mais atendendo aos requisitos e será migrado tudo para Oracle. Agora imaginem a cena. 1500 stored procedures, 2500 triggers, umas 1000 tabelas e alguns bilhões de registros tendo que ser migrados. Delícia não? Então se não quer passar por esse tipo de dor de cabeça, deixe sua regra de negócio na aplicação
tipo, eu num so mto fã d bancos pagos (principalmente c for da m$), prefiro trabalhar com bancos free…(o unico banco pago q eu trabalharia eh o oracle)
num consigo entender esse negocio d vcs fazerem um sist. p/ um banco e o cliente ter outro…
Banco de dados eh como camisinha: uns dizem que tira toda a graca, outros gostam da sensacao de seguranca que ela oferece, mas todo mundo acha horrivel quando usa uma que nao serve direito.
