Fórum Porque usar ODBC #595807
28/07/2018
0
Boa noite,
Pessoal preciso de uma opnião de algum especialista.
Seguinte: Desenvolvo sistemas em Delphi e sempre utilizei conexões ODBC para me conectar com Banco seja ele qual for e sempre fiz assim porque numca tive problemas e todas as grandes desenvolvedores de software que eu conheco (Senior, Totus, Mega e algumas outras utilizam assim).
Ocorre que agora estou iniciando um projeto e estou sendo muito questionado por utilizar ODBC, me dizem que estou colocando um complicador a mais no sistema sendo que eu poderia acessar diretamente sem ele ( estou utilizando mysql).
Só que eu não gosto da ideia mudar uma estrutura apenas porque alguns analistas querem que eu mude, precisa ter alguma justificativa técnica pra isto.
Por tanto eu preciso de algum argumento técnico, uma matéria ou algo que justifique a utilização ou não do uso de ODBC.
Alguem pode me ajudar nisto, alguem tem algum argumento técnico falando dos prós e contras da utilização de conexões ODBC.
Pessoal preciso de uma opnião de algum especialista.
Seguinte: Desenvolvo sistemas em Delphi e sempre utilizei conexões ODBC para me conectar com Banco seja ele qual for e sempre fiz assim porque numca tive problemas e todas as grandes desenvolvedores de software que eu conheco (Senior, Totus, Mega e algumas outras utilizam assim).
Ocorre que agora estou iniciando um projeto e estou sendo muito questionado por utilizar ODBC, me dizem que estou colocando um complicador a mais no sistema sendo que eu poderia acessar diretamente sem ele ( estou utilizando mysql).
Só que eu não gosto da ideia mudar uma estrutura apenas porque alguns analistas querem que eu mude, precisa ter alguma justificativa técnica pra isto.
Por tanto eu preciso de algum argumento técnico, uma matéria ou algo que justifique a utilização ou não do uso de ODBC.
Alguem pode me ajudar nisto, alguem tem algum argumento técnico falando dos prós e contras da utilização de conexões ODBC.
Amauri Alves
Curtir tópico
+ 0
Responder
Post mais votado
31/07/2018
Tenho sim,
ODBC é geralmente uma dor de cabeça e eu vou te explicar o porque.
O ODBC é uma "camada" ou "componente", como você quiser chamar, a mais que você adiciona no seu sistema.
Ponto 1.
-O seu sistema irá gerar a query para o banco de dados, enviar ao componente do ODBC, que irá enviar para o Driver de ODBC do seu Banco de dados, este "de-para" tem um custo no seu sistema.
Ponto 2.
-O ODBC pode ter problemas com sistemas 64 bits, como é uma tecnologia legada ele pode possuir um problema na migração para sistemas mais novos (windows server 2016 por exemplo).
Ponto 3.
-O ODBC deve ser configurado no ambiente, portanto se for Windows no caso você terá que replicar para cada máquina, para aplicações pequenas não tem problemas, mas para sistemas corporativos com 10 servidores de front-end e 16 servidores de backend o ODBC deve ser configurado em cada máquina, gerando possíveis falhas humana.
Ponto 4.
-A configuração fica no ambiente e fora do escopo do código, portanto se não tiver uma documentação correta ou uma validação se a conexão ODBC existe, se você "baixar" os fontes e executar na máquina ele não irá funciona. Necessitando de uma configuração prévia. Nos dias de hoje, com DevOps, compilações e instalações manuais e o software sendo responsável por si mesmo, não faz tanto sentido usar ODBC.
Ponto 5.
-Não são todos os bancos de dados que possuem conexão ODBC. Exemplo: Procura um ODBC para Sybase. (difícil de encontrar)
Não tem nada de errado você utilizar, porem está em desuso e para sistemas novos esta ferramenta não é mais utilizada.
ODBC é geralmente uma dor de cabeça e eu vou te explicar o porque.
O ODBC é uma "camada" ou "componente", como você quiser chamar, a mais que você adiciona no seu sistema.
Ponto 1.
-O seu sistema irá gerar a query para o banco de dados, enviar ao componente do ODBC, que irá enviar para o Driver de ODBC do seu Banco de dados, este "de-para" tem um custo no seu sistema.
Ponto 2.
-O ODBC pode ter problemas com sistemas 64 bits, como é uma tecnologia legada ele pode possuir um problema na migração para sistemas mais novos (windows server 2016 por exemplo).
Ponto 3.
-O ODBC deve ser configurado no ambiente, portanto se for Windows no caso você terá que replicar para cada máquina, para aplicações pequenas não tem problemas, mas para sistemas corporativos com 10 servidores de front-end e 16 servidores de backend o ODBC deve ser configurado em cada máquina, gerando possíveis falhas humana.
Ponto 4.
-A configuração fica no ambiente e fora do escopo do código, portanto se não tiver uma documentação correta ou uma validação se a conexão ODBC existe, se você "baixar" os fontes e executar na máquina ele não irá funciona. Necessitando de uma configuração prévia. Nos dias de hoje, com DevOps, compilações e instalações manuais e o software sendo responsável por si mesmo, não faz tanto sentido usar ODBC.
Ponto 5.
-Não são todos os bancos de dados que possuem conexão ODBC. Exemplo: Procura um ODBC para Sybase. (difícil de encontrar)
Não tem nada de errado você utilizar, porem está em desuso e para sistemas novos esta ferramenta não é mais utilizada.
Carlos Augusto
Responder
Gostei + 1
Mais Posts
01/08/2018
Emerson Nascimento
As grandes desenvolvedoras continuam utilizando ODBC e acredito que sempre irão utilizar. E porquê? Porque elas desenvolvem para vários bancos de dados.
Você citou a TOTVS. O Protheus pode ser utilizando com banco de dados MSSQL, Oracle, PostGreSQL, e outros (praticamente qualquer SGBDR que tenha um driver ODBC, mesmo que não esteja homologado pela TOTVS). Ou seja: o cliente escolhe o banco de dados que quer utilizar, até porque pode existir um outro sistema no cliente que já utilize um banco de dados, não obrigando a compra de um outro.
E se a TOTVS não utilizasse ODBC, mas ainda assim quer oferecer a opção de vários bancos de dados? Teria que tratar no fonte, o que complica o desenvolvimento. E ela precisa oferecer mais de uma opção de banco de dados, para não configurar a 'venda casada', porque as grandes desenvolvedoras geralmente utilizam bancos de dados comerciais.
Se o programa que você está desenvolvendo utilizar um ÚNICO banco de dados (MySQL, no caso - e cuidado para que não seja venda casada) eu acho correto o desenvolvimento diretamente para o banco, o que, além de facilitar a configuração no cliente final, deve gerar algum ganho de performance, porque terá uma camada a menos para passagem de informações/dados.
Mas tome cuidado com uma coisa: se o sistema que você está desenvolvendo for vendido/comercializado, o MySQL deixa de ser gratuito.
Pelo que eu sei o MySQL somente é gratuito para software free/opensource. Como exemplo de bancos de dados totalmente gratuitos, posso citar Firebird e PostGreSQL.
Você citou a TOTVS. O Protheus pode ser utilizando com banco de dados MSSQL, Oracle, PostGreSQL, e outros (praticamente qualquer SGBDR que tenha um driver ODBC, mesmo que não esteja homologado pela TOTVS). Ou seja: o cliente escolhe o banco de dados que quer utilizar, até porque pode existir um outro sistema no cliente que já utilize um banco de dados, não obrigando a compra de um outro.
E se a TOTVS não utilizasse ODBC, mas ainda assim quer oferecer a opção de vários bancos de dados? Teria que tratar no fonte, o que complica o desenvolvimento. E ela precisa oferecer mais de uma opção de banco de dados, para não configurar a 'venda casada', porque as grandes desenvolvedoras geralmente utilizam bancos de dados comerciais.
Se o programa que você está desenvolvendo utilizar um ÚNICO banco de dados (MySQL, no caso - e cuidado para que não seja venda casada) eu acho correto o desenvolvimento diretamente para o banco, o que, além de facilitar a configuração no cliente final, deve gerar algum ganho de performance, porque terá uma camada a menos para passagem de informações/dados.
Mas tome cuidado com uma coisa: se o sistema que você está desenvolvendo for vendido/comercializado, o MySQL deixa de ser gratuito.
Pelo que eu sei o MySQL somente é gratuito para software free/opensource. Como exemplo de bancos de dados totalmente gratuitos, posso citar Firebird e PostGreSQL.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)