PC Toledo

Pessoal,

Estive conversando sobre esses assuntos com alguns amigos e gostaria de trocar mais algumas informações tipo:

- estou interessado em migrar clipper -> xHarbour, e futuramente pra modo visual incorporando modulo que trabalhe com palmtops (smarts);

nesse aspecto é mais indicado continuar com DBF ou migrar pra MySql.
não questiono a credibilidade daqueles que ja me opinaram, apenas quero coletar mais informações sobre a discução.

valeu.

Tche....eu recem toh usando o xHarbour e toh usand o veho DBF ainda nos meus sistemas......mas andei conversando com o Vailton pra min começar a usar o MYSQL...e estou dando uma estuda para ver como funciona esse novo bichinho que vou colocar em meus sistemas que se chama SQL.....não sei como funciona ainda...mas o pouco que jah olhei nas apostilas ele dah de 1000 no velho DBF .....mas falando em PALM...ai não sei como funciona e não faço nem ideia de sua compatibilidade e etc....


Abraços

Eu particularmente adoro o DBF pela sua independencia e simplicidade de uso.

Na empresa em que eu trabalho o sistema é 99% DBF (120 arquivos (dbf+cdx) com quase 500mb de dados)

Porem comparando com outros bancos (como o mysql) surgem inevitavelmente as limitações.

O 1% restante aqui é por conta do mysql que é responsável pelos dados do site da empresa que uso em conjunto com PHP.

Já começei a fazer alguns testes (com sucesso) no xHarbour e pretento aos poucos ir migrando as tabelas, mas só depois de muitos testes de desempenho e estabilidade.

Sou novo mundo do mysql, ainda estou estudando todo o seu potencial, mas já posso ver que é bem grande.

Meu pensamento para próximos projetos: para pequenas e médias aplicações e aplicações standards eu vou usar DBF, para médios e grandes projetos em rede ou na web, será mysql.

Não conheço muito do Mysql, mas sendo SQL com certeza é infinitamente melhor e mais estável que DBF, a única grande vantagem que vejo no DBF é sua simplicidade. Na minha opinião para sistemas pequenos usar DBF é uma ótima saída, para sistemas mais abrangentes e robustos com certeza SQL é a melhor solução.

A muiiiiiiito tempo atrás (91-92) conheci o DB2 (não é dBase II) e me familiarizei com o conceito de SQL, já era um senhor Banco de Dados usado em mainframes, era extremamente confiável, rápido, eficiente e muiiiito maleavel.

Até logo.

Marcelo

Caros, sou como vcs! Gosto de colher informacoes antes d td.
Afirmo q o MySQL eh otimo mas eh um BD voltado para solucoes WEB, veja bem n quero dizer q funcionaria somente para WEB, eh como um carro off-road q tb anda no asfalto mas foi feito para terrenos d terra, o MYSQL tb eh assim, foi feito para solucoes WEB mas poderia ser usado para LAN. Mas sem duvida eh uma ferramenta execelente.

Marcos Roberto.

Boa tarde.
Estou usando já faz uns 2 anos eu acho ou mais, o Mysql 5 em clientes de médio porte mais de 70 usuários, o sistema com a combinação de xharbour+mediator+mysql 5 é a melhor versão que constitui até hj orgulho do papai...rs...
Durante o periodo natalino com a demanda, os chamados de suporte eram constantes devido problemas relacionados a base de dados e queda de performance, problemas desse tipo simplesmente sumiram...graças a Deus...
Eu postei ano passado eu acho um exemplo mostrando o uso dessas ferramentas logo que obtive resultados positivos explicando a todos como fazer uso e aproveitá-las a nosso favor.
Mais informações visitem a seção Código Fonte.


:xau

Amigos,

Me deixa participar também,

Qual a melhor solução de banco de dados, vamos dizer para pequeno/médio porte e desktop, usar dbf, mysql, postgree, firebird ? Sendo que todos estes bancos de dados poderemos usar com o nosso xharbour.

Quem arrisca dizer? Eu ainda estou com meu velho dbf tmb, mas precisamos caminhar.

ps. Como se pronuncia xharbour? Seria "équisrarbour"?

Valeu? :)Pos

Momente depende do seu volume e tráfego de informações.
O dbf é suficiente bom e atende necessidades para locais com um volume pequeno de informações.
Agora em mtas empresas grandes além do tráfego considerado de informações fora que muitas soluções procuram se integrar com a web, por exemplo no meu caso, o mysql além de cuidar do sistema interno também oferece informação no site on-line pro cliente do meu cliente...rs.
Eu migrei para solucionar meus problemas tanto de atualização informação do site que antes eu enviava um texto para processo...e para mais estabilidade do sistema.

Vou expressas minha opnião.

Eu ainda não me deparei com nenhuma empresa que tivesse necessidade "logica" de banco relacional, apesar de algumas usarem.

Em primeiro lugar, o grande problema dos DBFs são as unidades "montadas", que ao menor sinal de queda de energia parece que os buffers e trafego ficam corrompidos e as vezes são gravados assim nos indices e até mesmo nos DBF.

Com emulação de terminal problemas do tipo não existem mais, pois tudo fica no servidor. Alias, o banco relacional faz isto. A base fica local no servidor e todo o trafego é feito via Socket e sempre tem toda uma regra para se gravar as informações.

Em 3 anos analisando tudo quanto é tipo de codigo fonte, cheguei a consluão que:

1 - MySQL é robusto, mas com DBF rodando em emulação de termnal ele é tão bom quanto, e em muitas operações, por incrivel que pareça, DBF fica mais rapido que SQL, isto acho que mais devido a nossa forma habitual de programação, mas comprovadamente fica.

2 - MYSQL foi feito para ser o banco da internet, se quiser usar banco de dados empresarial e visando o trabalho que você terá use sempre POSTGRES, ele sim é bruto.

3 - Você só precisa de banco relacional quando a um acumulo de 40 ou 50 mil registros diarios para todas as bases do sistema, se você nao chega a isto, esquece, você não precisa ter pressa para migrar para base relacional, que a emulação de termnal em Linux e Windows te fornecerá os mesmos beneficíos de forma simples, e seu cliente não vai depender de alguem para administrar o banco de dados e servidor dele, pois já viu, isto sempre é necessário para se administrar novos usuários e coisas do tipo.

4 - DBF tem se comportado mais rapido para selecionar dados do que SQL, a quase 2 anos atrás eu migrei um sistema de uma pessoal de BH e sempre que faço uma migração no local eu entrego uma copia da CGILIB que estou montando, pois bem, este cliente contratou pessoal qualificado para montar o site da empresa dele, e eles só trabalham com PHP e MYSQL, mas por insistencia dele, fizeram uso da CGILIB disponibilizando dados DBF com indice CDX, e por incrivel que pareça, levaram um susto ao ver a velocidade do sistema rodando, comparando o mesmo site com qualquer outro servico que fizeram, as bases cheias e o sistema carrega as informações em menos de 1 segundo, o site então nem se fala, ficou a coisa mais linda, seguindo este exemplo, este memso pessoal fez o site de uma empresa chamada MST em BH, eles migraram o sistema para xHarbour e usaram a CGILIB para gerar o site, me passaram semana passada o login para que eu visse o resultado final, o site ficou bacana, tenho ate receio em dizer que usaram a CGILIB, ela foi só uma porta e a velocidade ficou assustadora, o proprio pessoal me montou o site falaram que não imaginavam que fosse possivel disponibilizar DBF online e nem que ficaria tão rapido e mais seguro que banco relacional (O DBF FICA FORA DE ROTA DOS NAVEGADORES E NAO TEM COMO SE CONECTAR VIA SOCKET AO SERVIDOR, INVASÃO SÓ SE FOR PELO FTP).

Porque fica rapido?

Imagino só, se você colocar MYSQL ou POSTGRES rodando local e um programa xHarbour com DBF, o DBF será acessado diretamente sem necessidade de um serviço paralelo. O banco relacional mesmo estando local continua trafegando via socket e precisa de seu "motor" gerenciando suas querys.

Falo de testes reais.

O BANCO RELACIONAL, é ótimo, magnifico, mas em grandes volumes de dados, ai sim, ele trabalha mais rapido que DBF, hoje tenho clientes que acumulam 50 mil registros em media por dia em DBF e não existe necessidade de migrar para banco relacional, tudo depende do sistema bem programado.

As empresas que mais tem acumulo de informações, geralmente são mercado atacadista, que tem grande volume de vendas e de pequenos produtos, mercados por exemplo, são muitos itens em um cupom fiscal, mesmo assim, é prudente, mesmo em banco relacional, estes movimentos mensais estarem separados.

Acho que tudo é uma questão mais de gosto do que de necessidade.

Quantos aos PALM, sempre programo palms sincronizando diretamente com a base DBF via internet ou mesmo via cabo ou GPRS ou o tipo de conexão que exitir.

É joia.

Minhas modesta opnião é: Para grandes volumes use banco relacional, se nao chegar neste patamar seus DBFs se comportarão melhor, pode ter certeza.

Em PDVs então, use somente DBF, seus cliente te darão menos dor de cabeça do que com banco relacional.

momente escreveu:Amigos,
ps. Como se pronuncia xharbour? Seria "équisrarbour"?

Também depende...

Se você usar o Uindous équispí... hehe

Dois Fatos:

Revista INFO EXAME - Edição dez/2006 - MySQL é eleito o melhor banco de dados do ano

Revista INFO EXAME - Edição abr/2007 - Pesquisa com as 100 empresas brasileiras que mais investem em TI - MySql ficou em 4º lugar no banco de dados mais utilizado por essas empresas... Microsoft SQL ficou na frente.

Minha modesta opinião:
1-) O sistema vai rodar local??? DBF dá de 10 a ZERO no MySQL. Neste caso DBF é bem mais rápido que MySQL.

2-) O sistema vai rodar em uma rede??? MySQL dá de 1000 a ZERO em DBF.
Experiência: Tenho um sistema em rede (20 estações) que quando era em DBF... um determinado relatório era gerado em quase 1 minuto e meio... Quando migrei para MySQL, o mesmo relatório foi gerado em +ou- 20seg. Já ouvi vários relatos de colegas que com DBF em rede... a medida que as maquinas vão acessando o sistema... o sistema vai ficando lento...

Jânio

Amigo Vagner,

Como funciona uma emulação de terminal com dbf?

Da pra explicar um pouco melhor isso ae para um pobre mortal programador?, hehe

valeu!

Amigos,

Eu devo estar fazendo uma pergunta muito ignorante mesmo!

Mas mesmo assim tento novamente, alguem pode me explicar como funciona exatamente um emulador de terminal?

Valeu!

momente escreveu:Mas mesmo assim tento novamente, alguem pode me explicar como funciona exatamente um emulador de terminal?

Apesar de nem estar na thread e a pergunta originalmente ter sido destinada a outra pessoa:

Emular um terminal é como nos anos 70, onde os terminais, todos burros, não faziam coisa alguma, além de receber a entrada pelo teclado e receber as informações de vídeo. A grosso modo era assim.

Hoje em dia, emular terminal é quase a mesma coisa de antes. Um software faz de uma máquina um servidor (uma máquina bem parruda, diga-se) e as estações, mesmo tendo alguma capacidade de processamento, agem como terminais burros. O software (DOS que seja) roda no servidor, que tem áreas de memória reservadas para cada estação. Na estação tudo acontece como se fosse local, mas tudo é processado remotamente no servidor. É claro que a qualidade final vai depender de quão bom for o servidor. Se carregá-lo demais, a coisa pode ficar muito ruim. Mas se houver hardware suficientemente bom, tornará até viável continuar usando DBF por mais algum tempo.

Do jeito que pintaram o quadro, DBF parece ser uma coisa tão boa que o mundo inteiro deveria abandonar seus SGBDs. )))

Não é bem assim, claro. Cada estação comerá uma parte da memória e do poder de processamento do servidor. Não é nada difícil imaginar que se o servidor estiver com muitas estações "penduradas" a qualidade final acabará desabando.

Ainda sou mais um bom gerenciador de bando de dados. Não o MySQL, que é mais dedicado à web. Até porque, disseram e eu acredito: ele pode se tornar mais lento que DBF se usado localmente. Claro. Como DBF não seria mais rápido que um banco de dados que bloqueia toda uma tabela se você quiser alterar um único registro? Por essas e outras eu prefiro o Firebird que funciona muito bem com acesso remoto e local. Não tem nada desse negócio de usar sockets para acesso local. Isso não existe. Quem desenvolve um banco de dados não é burro a esse ponto. A versão embutida (acesso local) do Firebird usa uma mísera DLL que acessa o banco de dados diretamente. Nunca testei se, localmente, DBF é mais rápido. Mesmo que seja, não tenho o menor interesse em me prender ao passado dos DBFs. Porque...

...Botando a discussão "velocidade" de lado, há muitas "features" que um gerenciador de banco de dados tem que o velho e desatualizado DBF nem chega perto, mesmo com RDDs mais modernos. SQL, stored procedures, triggers, views, memory tables, UDFs, constraints, generators, BLOBs, segurança, etc. Todas essas demais características já justificam totalmente enterrar os DBFs de vez.

Eu não estou falando do MySQL. Ele não é para desktop por enquanto. Será um dia. A MySQLAB, conforme artigos que li, está investindo pesado nisso. Mas hoje em dia, para desktop, eu prefiro o Firebird (leve) ou PostGreSQL (mais pesado), para citar apenas duas opções totalmente gratuitas. Mas se o assunto for missão crítica e/ou volume de dados excessivamente alto, a coisa muda de figura: é melhor esquecer a gratuidade e partir para uma solução proprietária: Oracle, por exemplo.

[]'s
Maligno
http://www.buzinello.com/prg

momente,me chama no MSN qualquer hora dessa que lhe mostro o caminho e faço uma demostração na pratica de como funciona um emulador de terminal !!.....se quiser tb. de uma procurada aqui no forum uma vez se não me engano eu vi algo na seção de codigo fonte !!

Abraços
Leonardo Machado