Valdir Posted April 28, 2015 Report Share Posted April 28, 2015 Pessoal... Não querendo gerar polêmica, pois bem sei que cada qual tem as suas preferências. Porém já ouvi muitos relatos aqui no Fórum sobre as Qualidades e Ineficiências de cada tipo de Banco de Dados Os que defendem o uso do BD Relacional baseiam-se no argumento da Segurança durante as Transações dos dados. Porém muitos que já usam este tipo, também reclamam da velocidade e confiabilidade se o Usuário não tiver uma estrutura de rede bem planejada e configurada. O amigo José Carlos Eonner e tantos outros defendem o uso da tecnologia da sql como fundamental para continuarmos a acompanhar o mercado. Já os que usam o tipo xBase, embora todos concordem que o item Segurança é o principal obstáculo a ser vencido, são convictos que se tiver uma programação limpa e com o Uso da Lógica correta, esse tipo de Banco de dados não deixa nada a desejar aos Relacionais. O meu amigo e mestre Vagner Wirts é um defensor entusiasta deste tipo de BD. Segundo ele, esse tipo de Dados além de ser mais rápido, também pode se tornar seguro. Recentemente outro amigo, o Rochinha que também é outro mestre, confirmou esse tipo de preferência. Então pergunto... Para nós simples mortais, qual é o melhor caminho ? abração. Ronaldbuch 1 Quote Link to comment Share on other sites More sharing options...
kleyber Posted April 28, 2015 Report Share Posted April 28, 2015 Grande Valdir, Não é surpresa pra ninguém que prefiro bancos SQL. Mas deixando de lado minha preferência, o melhor caminho é aquele que você domina e tem como gerenciá-lo. A grande questão é quando for passar para gerar teus sistemas na WEB, pois o DBF não irá funcionar, a não ser que se tenha um meio mundo de coisas no meio e que nem sempre dão conta do recado, quando são milhares de acessos, etc. Mas no que tange a desktop, sem dúvida DBF ainda tem uma vida longa. Portanto se teu espectro de sistemas ainda é desktop, DBF é a melhor opção. aferra 1 Quote Link to comment Share on other sites More sharing options...
aferra Posted April 28, 2015 Report Share Posted April 28, 2015 Grande Kleyber, sucinto e direto ao ponto, acrescentaria o seguinte: aprenda o SQL. entenda o seu funcionamento, hoje está tudo mudando, como sempre foi alias, e amanhã vc precise colocar isso no seu sistema vc não terá que aprender da noite para o dia, não terá que se desdobrar para entender, não fará gambiarras, enfim, terás o controle na sua mão... a pergunta: porque não aprender? P.S.: estou aprendendo c#, irei deixar de usar o fivewin??? de jeito nenhum, tem coisa que dá para acrescentar no fivewin com o que aprendi no c#. novato ainda Quote Link to comment Share on other sites More sharing options...
kleyber Posted April 28, 2015 Report Share Posted April 28, 2015 Aferra, Boa... também tem esse lado. É que muitos aqui não querem sair do lugar em que estão pra aprenderem coisas novas... mas você está certo. Aliás foi exatamente o que eu fiz. Hoje eu uso uma outra ferramenta para desenvolver meus projetos para WEB e estou satisfeito com os resultados. aferra 1 Quote Link to comment Share on other sites More sharing options...
Luiz Fernando Posted April 28, 2015 Report Share Posted April 28, 2015 faz apenas 3 anos que tenho meu sistema em mysql com comandos nativo em sql, posso garantir que comparar DBF com banco de dados relacional é uma coisa que não faz sentido, logico que muitos irão defender o DBF pois se seus sistema estão em DBF, isto sera o ganha pão deles, e eles estão mais que correto nisto, fiz isto também por muito tempo, mais podem ter certeza são duas coisas que não da nem para comparar... Obs: a um tempo atrás ninguém entendia nada de informatica, hoje o mercado esta diferente , deixei de pegar cliente potencial, que gostaram de meu sistema, aonde estava praticamente fechado, qdo descobriram que a base de dados era em DBF , simplesmente desistiram. Abs Luiz Fernando Quote Link to comment Share on other sites More sharing options...
emotta Posted April 29, 2015 Report Share Posted April 29, 2015 E pq não usar o melhor dos dois mundos??? Em meus sistemas mantemos sempre a compatibilidade com DBF. Em algumas rotinas usamos o ADO para fazer SELECT mesmo em DBF ou se o cliente tem uma estrutura melhor ele usa SQL (o Express ou o pago). Usamos SQLRDD pra fazer a conexão com banco. E como falei, temos o melhor dos mundos... Quando é mais vantagem usar DBSKI/LOOP usamos, quando é melhor usar SELECT/UPDATE usamos... Um não anula o outro... e temos as principais rotinas de calculo do sistema ou que movimentam uma grande massa de dados feitas em SQL de maneira rapida.... Mesmo em DBF da pra se usar SELECTs e fica sim com uma boa performance. Abraços e sigamos em frente Quote Link to comment Share on other sites More sharing options...
Valdir Posted April 30, 2015 Author Report Share Posted April 30, 2015 Amigos... Kleyber, Alessandro, Luiz Fernando e Eduardo. Inicialmente agradeço os esclarecimentos e sugestões apresentadas. A minha principal dúvida sempre esteve relacionada com o Custo Benefício que irei apresentar aos meus clientes no ato da negociação para a implantação do Sistema. Entendo que para se trabalhar com BD também seja necessário uma infra estrutura mínima para o resultado ser satisfatório. Infelizmente essa estrutura irá aumentar os Custos para eles e nem sempre todos estão dispostos a investir nisso. Por outro lado, embora não exista Custos Adicionais para os mesmos, sempre ficará aquela lacuna de segurança que os arquivos xBase irão apresentar. Hoje, a minha realidade é que meus clientes trabalham totalmente desktop e dificilmente irão trabalhar remotamente. Isso causa um grande desconforto e insegurança quando se fala em Arquivos Dbfs numa rede inadequada. Como foi observado anteriormente, entendo que o transtorno será o mesmo quando se fala em BD na mesma situação. Então acredito que o maior problema esteja relacionado com a Infra Estrutura da Rede de nossos clientes. É isso ou estou enganado ? Um abraço Quote Link to comment Share on other sites More sharing options...
emotta Posted April 30, 2015 Report Share Posted April 30, 2015 Valdir, o ponto é exatamente esse. Deixe a escolha para o seu cliente. Faça com que o seu sistema funciona nas duas maneiras, DBF ou SQL, e ele quem escolhe o que ele quer. Hoje faço isso para meus clientes. Se ele quer investir em servidor e segurança ele banca um SQL e pronto. Se ele nao pode no momento usa o DBF. Se ele tem uma maquina razoavel e que dê pra instalar um banco sem custo instale o SQL EXPRESS. Enfim, deixe a escolha pra ele. Se ele nao pode investir em banco com vc nao podera investir em banco com outro. O que não consigo entender é o pq do dilema, já que é possivel deixar o seu código compativel com SQL e DBF e o cliente escolher o que ele precisa. Amigos... Kleyber, Alessandro, Luiz Fernando e Eduardo. Inicialmente agradeço os esclarecimentos e sugestões apresentadas. A minha principal dúvida sempre esteve relacionada com o Custo Benefício que irei apresentar aos meus clientes no ato da negociação para a implantação do Sistema. Entendo que para se trabalhar com BD também seja necessário uma infra estrutura mínima para o resultado ser satisfatório. Infelizmente essa estrutura irá aumentar os Custos para eles e nem sempre todos estão dispostos a investir nisso. Por outro lado, embora não exista Custos Adicionais para os mesmos, sempre ficará aquela lacuna de segurança que os arquivos xBase irão apresentar. Hoje, a minha realidade é que meus clientes trabalham totalmente desktop e dificilmente irão trabalhar remotamente. Isso causa um grande desconforto e insegurança quando se fala em Arquivos Dbfs numa rede inadequada. Como foi observado anteriormente, entendo que o transtorno será o mesmo quando se fala em BD na mesma situação. Então acredito que o maior problema esteja relacionado com a Infra Estrutura da Rede de nossos clientes. É isso ou estou enganado ? Um abraço Quote Link to comment Share on other sites More sharing options...
kapiaba Posted April 30, 2015 Report Share Posted April 30, 2015 Tranka, dê uma olhadinha aqui: http://forums.fivetechsupport.com/viewtopic.php?f=6&t=30527 abs. Quote Link to comment Share on other sites More sharing options...
MatheusFarias Posted April 30, 2015 Report Share Posted April 30, 2015 Bem a um ano tive uma boa experiencia de migração para o MySQL usando o SQLRDD. Não tenho nada contra o dBase, foi o primeiro que aprendi, entretanto conheço algumas linguagens a mais e alguns frameworks comerciais que ja faz o que o CLIPPER fazia a muito tempo, por exemplo: para quem trata com java para web e uso os novos padroes de projeto como dados relacionados dentro de uma classe ele automaticamente gera do DB e faz a cada de persistencia onde voce chama os comando dos bancos e as alteraçoes no objeto nao obstante temos um exemplo classico no clipper :select cliente // no java eles chamam isso de camada de persistencia append blank // no java eles chamam isso de camada de persistencia replace nome with vnome replace idade with 19 commit // no java eles chamam isso de camada de persistencia Nos novos Frameworks seriaDBConnection.Insert() // classe da camada de persistenciaoCliente.setNome(tTextFieldNome.getText()) // o proprio framework faz a tradução da atribuição e sabe q o objeto oCliente é um Cliente do DB oCliente.setIdade(tTextFieldIdade.getText()) DBConnection.commit() // classe da camada de persistencia Então colegas aliados ao que hoje no java é novidade o abençoado do Nosso Fivewin Ja nasceu assim mas como o nome carrega muita coisa não temos esse credito todo. No que tange aos beneficios do MySQL acredito que é preciso conhecer BEEEEEEEEMMMM a linguagem para banco que tem umm Poder incoparevel com DBF gaste um tempo no Site da Oracle e veja o tanto de recursos que voce pode ter com essa ferramente, e no trivial tambem da para ser adptado, somente é preciso gastar tempo e não ter medo da mudança. Recomendo que migrem Quote Link to comment Share on other sites More sharing options...
Ariston Santos Posted May 1, 2015 Report Share Posted May 1, 2015 No post que Rochinha defendeu o DBF ou também o fiz, por isso, aqui vai mais uma opinião. Em todos os casos de problemas com DBF que eu tive, a origem do problema foi: rede (1%), vírus (9%) ou BP/USB* (90%). Recentemente um cliente me ligou dizendo que as contas a receber estavam sumindo. Fui lá para entender como eles trabalhavam, dei uma desculpa de que o servidor poderia estar com vírus, no final do expediente mudei o servidor para outro computador e fui para casa testar o programa. (Já fez isso alguma vez?) Resultado da análise: descobri que ao converter movimentos em espera para venda eu estava excluindo as contas a pagar para salvar novamente, como se fosse uma alteração de uma venda a prazo. O detalhe é que o movimento em espera tinha um código e a venda (resultado da conversão) tinha outro, assim, eu estava excluindo contas de outra venda, resultando no dito desaparencimento. Corrigi o problema e, na manhã seguinte, atualizei no cliente e pedi para ele acompanhar a movimentação. Se parrasse de sumir contas, tava provado que o problema era vírus no servidor anterior. (kkk) Problemas parecidos tive com: Duplicação ou sumiço de cadastros, não baixar estoque, corrompimento de índices, e aí vai... Nesse ínterim, desgostoso com tantos problemas de DBF (a culpa nunca é do programador), comecei a estudar bancos de dados relacionais, o que de fato é muito fácil, diga-se de passagem. Hoje estou migrando, aos poucos, e em passo de tartaruga, para SQL puro, com SQLRDD. Até porque também já estou desenvolendo para Android que vem com SQLLite, e sites, que usam MySQL, MS-SQL e outros, dependendo do servidor de hospedagem. Para quem está começando sugiro partir logo para bancos de dados relacionais por ser esse o futuro dos bancos de dados. Mas ainda garanto que, DBF bem trabalhado, não dá dor de cabeça (ou dar, senão, não teria que ser bem trabalhado). --- * BP = Burrice de Programador / USB=Usuário Super Burro. kapiaba 1 Quote Link to comment Share on other sites More sharing options...
gibaf Posted May 5, 2015 Report Share Posted May 5, 2015 E pq não usar o melhor dos dois mundos??? Em meus sistemas mantemos sempre a compatibilidade com DBF. Em algumas rotinas usamos o ADO para fazer SELECT mesmo em DBF ou se o cliente tem uma estrutura melhor ele usa SQL (o Express ou o pago). Usamos SQLRDD pra fazer a conexão com banco. E como falei, temos o melhor dos mundos... Quando é mais vantagem usar DBSKI/LOOP usamos, quando é melhor usar SELECT/UPDATE usamos... Um não anula o outro... e temos as principais rotinas de calculo do sistema ou que movimentam uma grande massa de dados feitas em SQL de maneira rapida.... Mesmo em DBF da pra se usar SELECTs e fica sim com uma boa performance. Abraços e sigamos em frente ola poderia, por favor, postar um demo de como fazer select em dbf ? obrigado Quote Link to comment Share on other sites More sharing options...
emotta Posted May 5, 2015 Report Share Posted May 5, 2015 Gibaf estou aguardando sua resposta ao meu email... Veja la e quando puder responda... Quanto ao exemplo segue um bem simples, divirta-se FUNCTION QueryADO() LOCAL oConexionAdo := CreateObject("ADODB.Connection") LOCAL oRecordSet := CreateObject("ADODB.Recordset") Local cSQL := "SELECT * from AFP" Local nFields oConexionAdo:Open("Driver={MySQL ODBC 3.51 Driver};Server="+ALLTRIM(cHost)+";Port=3306;Database="+ALLTRIM(cDataBase)+";User="+ALLTRIM(cUser)+"; Password="+ALLTRIM(cPassword)+";Option=3;") oRecordSet:CursorLocation := 3 // adUseClient oRecordSet:CursorType := 3 // adOpenStatic oRecordSet:ActiveConnection:= oConexionAdo oRecordSet:Open(cSQL) //quantidade de campos nFields := oRecordSet:Fields:Count IF !oRecordSet:Eof() oRecordSet:MoveFirst() //While nos registros While !oRecordSet:Eof() For nI := 1 To nFields cNomeCampo := Alltrim(oRecordSet:Fields:Item(nI-1):Name) //aqui pega o nome do campo uConteudoCampo := oRecordSet:Fields:Item(nCpoAtu):Value //aqui pega o conteudo do campo Next oRecordSet:MoveNext() //move para o proximo registro EndDO EndIf Return ola poderia, por favor, postar um demo de como fazer select em dbf ? obrigado Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.