MySql com Java

Nem melhora nem piora.

Hummm…
Não temos nada então implementado para usar código Java, no BD, ou algo do tipo né?

Obrigado.

lbvitoriano:

Hummm…
Não temos nada então implementado para usar código Java, no BD, ou algo do tipo né?

Obrigado.

??? Não entendi :lol:

Então, na verdade o q eu quero dizer é…

Existe alguma vantagem para eu utlizar MySql, ao invés de outros bancos do mesmo nível, qdo meu sistema for feito em Java? Tem algum beneficio nisso, ou indifere?
Seja para colocar regras de negócio no BD, ou simplesmente usá-lo como um repositório…em ambos os casos, o q mudaria do Mysql, para outros…?

Abraços…

Ou: eu sou suspeito pra falar do MySQL, porque se trata do meu SGBD favorito.

Como vantagens, acho que as principais poderiam ser:

• Performance: excelente
• Estabilidade: incrível
• Resistência a falhas: excelente

E, um fator interessante mas normalmente ignorado pelos desenvolvedores: motores de armazenamento plugáveis.
Ao contrário do SQL Server, por exemplo, que armazena os dados sempre no mesmo formato, o MySQL permite a utilização de motores de armazenametno diferentes, como por exemplo XML, arquivos texto, etc. É um recurso muito interessante, porém ainda muito negligenciado.

Certo…

Mas me diga, como vc costuma trabalhar o seu sistema Java com Mysql? Utiliza views, SP`s, triggers? Ou então como utliliza esse esquema de motores de armazenamento plugáveis?

Obrigado.

Trabalho com o MySQL como seria com qualquer bom SGBD: uso todos os recursos que tenho direito, como triggers, stored procedures, views, etc. O modo como trabalho com estes recursos é exatamente o mesmo (do ponto de vista de uma aplicação Java) que eu teria com o Oracle, SQL Server, etc, pois o JDBC/ORM isola minha aplicação das especificidades de funcionamento do banco de dados.

(é fato: SGBDs hoje são vistos mais como comodites do que plataformas de desenvolvimento, tal como há 10, 20 anos atrás)

Com relação ao uso dos motores de armazenamento plugáveis, é algo transparente pra nós. Basicamente, o utilizamos no momento de criação da tabela.
Por exemplo: se temos uma tabela de log, usamos o formato MyISAM, se for uma tabela temporária, InMemory, se for para usar integridade referencial, InnoDB, e por ai vai.

O que já vi rolar demais é uma certa galerinha do mal dizer que o MySQL é um banco de dados para empresas de pequeno porte, o que não é verdade de modo algum.
Trabalho com algumas tabelas que possuem milhões de registros e a performance fica práticamente inalterada. É realmente incrível a qualidade do bichinho.

É então, nós aqui temos o sistema rodando com 3 bancos distintos MySql, Oracle e Sql Server, de acordo com o q o cliente quiser, bastar mudar um parametro e pronto…mas claro isso envolve um desenvolvimento muito custoso…pois os selects tem q ser individuais, alguns tratamentos de banco tb, mas para o usuário isso fica totalmente transparente…

Porém estou tentando entender se a compra do MySql pela Sun, trouxe alguma mudança com relação a conexão, performance, otimização…porém pelo q vc mesmo já disse não mudou nada, nem pra melhor e nem para pior…eu pensei q talvez o BD estivesse agora aceitando algum comando em Java dentro dele, ou algo do tipo, porém pelo q ja vi do assunto, sem chance…

Preciso otimizar alguns processos aqui, estou estudando a possibilidade de colocar algumas coisas em SP`s, e triggers…e tb verificando se compensa utilizar o JasperServer, para tentar melhorar o consumo de memória qdo rodo os relatórios q eu tenho, é claro q tb estou analisando os virtualizadores que o Jasper oferece para avaliar estas questões…enfim, de td um pouco…rs

Obrigado pelas dicas, se estiver algo mais a acrescentar…fique a vontade…

Nao consigo gostar do MySQL, é o velho ditado a primeira impressao é a que fica, e a minha foi com a versao 3.5 alguma coisa, eu sempre usei Firebird, e no quesito sql ansi o bixo era bem completo, quando tive o bendito contato com MySQL e fui fazer minhas consultas com os joins da vida, BUMM faltava varios comandos, fui fazer FK nao achei as benditas InnoDB, acho que tinha, mas como eu nao conhecia, depois achei bem tosco(voce citou como beneficio) esse negocio de ter que criar tabelas diferentes se quisesse ter integridade referencial.
Mass ja sei que hoje na versao 5 o bixo ta bem melhor, mesmo assim peguei birra.

Hoje quando penso em BD livre e robusto a minha escolha é PostGreSQL.

Com relação ao que voce citou de rodar java, postgresql tem o PL/JAVA, no Oracle tambem é possivel implementar procedures usando java.

Então mas desde esta versão que vc citou, já mudou bem o BD viu…
Talvez um dia desses valha a pena vc pegar e reconsiderar, testar ele com mais afinco nas ultimas versões…e tal.

No que precisei, nunca tive problemas…sendo com muito ou poucos registros, nem fazia diferença, claro o q muda é a maneira como as tabelas foram montadas, os acessos aos dados é feito…isso tudo influencia…mas é um bom BD sim…

kicolobo:

Trabalho com o MySQL como seria com qualquer bom SGBD: uso todos os recursos que tenho direito, como triggers, stored procedures, views, etc. O modo como trabalho com estes recursos é exatamente o mesmo (do ponto de vista de uma aplicação Java) que eu teria com o Oracle, SQL Server, etc, pois o JDBC/ORM isola minha aplicação das especificidades de funcionamento do banco de dados.

(é fato: SGBDs hoje são vistos mais como comodites do que plataformas de desenvolvimento, tal como há 10, 20 anos atrás)

Com relação ao uso dos motores de armazenamento plugáveis, é algo transparente pra nós. Basicamente, o utilizamos no momento de criação da tabela.
Por exemplo: se temos uma tabela de log, usamos o formato MyISAM, se for uma tabela temporária, InMemory, se for para usar integridade referencial, InnoDB, e por ai vai.

O que já vi rolar demais é uma certa galerinha do mal dizer que o MySQL é um banco de dados para empresas de pequeno porte, o que não é verdade de modo algum.
Trabalho com algumas tabelas que possuem milhões de registros e a performance fica práticamente inalterada. É realmente incrível a qualidade do bichinho.

A minha questão agora é a seguinte…ainda falando sobre performance…
Se eu mandar executar um comando select, direto da minha aplicação em Java, vai ter alguma diferença se eu colocar ele dentro de uma SP, e chamar esta SP pelo Java?

Alguém sabe…?

Não posso dizer muito sobre o MySQL especificamente, mas o que dizem os caras do BD, é que sim, pois o comando ja fica pre-compilado e o BD “ja sabe o caminho das pedras” vamos dizer assim.

Porem eu nao gosto de programação orientata a procedures, talves algum SQL muito complexo que que seja mais pesado compense.

É isso é o q dizem q é pré-compilada e tal, mas será q na prática é mesmo o q acontece?
Existe esse ganho de performance, em usar a SP para executar um select, ou direto da minha aplicação eu teria o mesmo resultado?..

lbvitoriano:

É isso é o q dizem q é pré-compilada e tal, mas será q na prática é mesmo o q acontece?
Existe esse ganho de performance, em usar a SP para executar um select, ou direto da minha aplicação eu teria o mesmo resultado?..

Pra consultas simples (muitos joins numa consulta nao faz com que ela deixe de ser simples) nao vai ter grande diferenca, talvez nenhuma. Eu so uso stored procedures para processos muito pesados, como uma recontabilizacao por exemplo, que vai ler e atualizar milhoes de registros, algo que nao vai ser executado em menos de uma hora, mesmo por procedure.

Fora esses casos, normalmente o ganho de performance é minimo e nao compensa a complexidade de voce “espalhar” as regras para todo lado. Alem de que as linguagens de banco de dados tem muito menos recursos dos que as linguagens de programacao, pelo menos na maioria dos bancos, entao muitas vezes voce pode “sofrer” pra implementar uma regra no db que seria muito simples em java.

É uma visao pessoal minha, baseada na minha experiencia, mas nao gosto e nao recomendo o uso de triggers e stored procedures, a nao ser em caso em que sao realmente necessarias.

Pra te ser sincero… nunca vi diferença alguma em desenvolver em um banco em especial porque o jdbc é tudo padrão… A única diferença está na hora de consultar dados para testes e configurações…

Atualmente eu mal crio tabelas porque o JPA faz tudo automático…

Então, mas se fizermos algumas alterações nos BD`s como indices, alguns ajustes de configuração e tal, eu acho q mesmo usando JDBC, podemos sentir uma diferença…

Vcs não acham?

Concordo com o YvGa.
Triggers e SPs só em casos raros. No caso das triggers, os casos mais raros possíveis. Já me incomodei tanto com regras de negócio embutidas nelas, e que magicamente alteravam o fluxo que cheguei a conclusão que só são uteis em raros casos de integração de sistemas.

Sobre ser transparente o BD usado, graças ao JDBC:
ontem mesmo tive MAIS um problema com esse tipo de coisa
Graças ao driver JDBC do Oracle (e ao meu querido cliente, que se recusa a atualizar a versão do driver dele) tive que usar uma função específica do Oracle para carregar um Clob =/

clone_zealot:

Concordo com o YvGa.
Triggers e SPs só em casos raros. No caso das triggers, os casos mais raros possíveis. Já me incomodei tanto com regras de negócio embutidas nelas, e que magicamente alteravam o fluxo que cheguei a conclusão que só são uteis em raros casos de integração de sistemas.

Sobre ser transparente o BD usado, graças ao JDBC:
ontem mesmo tive MAIS um problema com esse tipo de coisa
Graças ao driver JDBC do Oracle (e ao meu querido cliente, que se recusa a atualizar a versão do driver dele) tive que usar uma função específica do Oracle para carregar um Clob =/

Eu estou ligado… provavelmente deve ser a versão 4 … em que agente tem que fazer uma puta função para carregar CLOB e BLOB … já a versão 6 basta vc fazer um getByte ou getString

É mesmo cada dia nos deparamos com novos problemas, pq muda a versão do BD, ou a do Java, e sempre algo pra melhor ou pior aparece…rs

Enfim, para trabalhar melhor com BD`s, vc acham necessário um bom ajuste nos indices, mesmo que para o JDBC possa tudo isso parecer transparente?

lbvitoriano:

É mesmo cada dia nos deparamos com novos problemas, pq muda a versão do BD, ou a do Java, e sempre algo pra melhor ou pior aparece…rs

Enfim, para trabalhar melhor com BD`s, vc acham necessário um bom ajuste nos indices, mesmo que para o JDBC possa tudo isso parecer transparente?

Sempre. Lembre-se: o JDBC só acessa o BD que está uma camada abaixo na sua arquitetura.
Se esta camada (o BD) não estiver redonda, de nada adianta a portabilidade do Java, pois sua performance será uma merda.

kicolobo:

lbvitoriano:

É mesmo cada dia nos deparamos com novos problemas, pq muda a versão do BD, ou a do Java, e sempre algo pra melhor ou pior aparece…rs

Enfim, para trabalhar melhor com BD`s, vc acham necessário um bom ajuste nos indices, mesmo que para o JDBC possa tudo isso parecer transparente?

Sempre. Lembre-se: o JDBC só acessa o BD que está uma camada abaixo na sua arquitetura.
Se esta camada (o BD) não estiver redonda, de nada adianta a portabilidade do Java, pois sua performance será uma merda.

É sempre pensei desta forma tb…mesmo pq lido com tres bancos diferentes para a mesma aplicação…
Não queria usar o BD apenas como um simples repositório, mas sim algo bem trabalhado…para consultas rápidas, e inserções otimizadas…

Para tudo. Acho que esta havendo uma confusão aqui! Como assim transparente?? O comando select que tu fizer la na tua classe é EFETIVAMENTE o select que vai rodar no BD, ou seja se tu mudar tudo muda. Entao a criação de indices vai sim afetar teus comandos.

Certo então era isso mesmo q eu queria chegar…o BD afeta sim, num basta deixar o JDBC agir…era isso…blz!