DataWare ou Edits?

sim sim, sempre tive essa duvida tbm ... :roll:

Olá pessoal,

Nâo sou o maior entendido do Delphi mas vou deixar minha opinião.

Os controles conectados são realmente uma mão-na-roda porém desenvolvendo neles não me sinto no controle da situação. Com tudo muito automático eu vejo que os problemas sempre vão acontecendo e as vezes rastreá-los é uma complicação.

Não sei se estou certo, mas quando se trabalha conectado e se faz um Edit no DataSet o banco abre uma transação pra edição daquele registor, e isso não é bom pois pode cuasar vários problemas se vc tem 200 usuários no sistema.

Eu trabalho totalmente desconectado. O máximo de processamento eu coloco no banco de dados pois estou tentando um projeto onde o banco de dados será acessado remotamente. Tenho apenas um Data Module onde tem o Connection (ZConnection da Zeos). Em cada formulário eu coloco os objetos ZStoredProcedure para operações de Inclusao, Alteração e Exclusão e objetos ZQuery para a busca de dados. Sempre que preciso exibir um registro eu abro a query (que faz um Select em alguma View do banco) e depois atualizo na mão os edits, combos, etc.

Desta forma com certeza o desenvolvimento fica mais lento porém tenho o controle da situação. Na procedure GravarRegistro eu abro a transação,tento efetuar a gravação, e depois faço o Commit ou Rollback.

Sei lá.. eu estou num grande projeto que de cara estou com 62 tabelas com apenas 1 mes de projeto e trabalhando conectado não serve pra mim. Consegui vários componentes todos freeware (PEdit, NextGrid e Fortes Report) e desta forma estou tendo uma qualidade muito grande no meu sistema.

Coloquem suas opiniões ae pra gente discutir, é um bom assunto.

Vlw!

romulocpd, vc coloca componentes de acesso ao BD no formulario??
nao sou expert, estou apenas inicando, mas creio que isso nao seja uma boa pratica ... usuarios mais experientes por favor postem suas opinioes!!

tbm nao sei como esta estruturado seu projeto, eu estou trabalhando em um projeto de mais ou menos 50 tabelas ... utilizo DBEdtis e isso no meu caso me ajuda muito pois nao preciso criar rotinas para carregar dados nos edits, sendo que existem tabelas com uns 50 campos hehehe ...

eu utilizo dbedits, e centralizo meus componentes de acesso a dados do bd no datamodule e alterno as tabelas entre esses poucos componentes que estao contidos nele ... tenho um certo trabalho para escrever o codigo mas isso tbm me possibilita a possibilidade de nao permanecer conectado quando nao é necessario, fico conectado no bd somente para realizar as operacoes e depois libero a conexao!!!! quando necessito de alguma informacao adicional de alguma tabela, eu crio dinamicamente utilizo o que preciso e depois destruo o componente ...

sou um iniciante como ja disse, estou tocando o projeto com muita dificuldade e sozinho mas o bom é que estou aprendendo muito ..

é isso amigo!
[]ss

Bom, vou colocar minha humilde opnião:

Trabalhar conectado, como disse o [b:26f756f7a2]Romulo[/b:26f756f7a2], realmente não é bom, mesmo o sistema não sendo remoto como o dele. O maior problema é a lentidão, porém não necessariamente você precisa conectar-se totalmente ao banco só porque trabalha com componentes DataWare.

Os componentes DB´s podem ser utilizados para facilitar a atualização dos dados de um único registro. Onde você tem uma pesquisa prévia em SQL que traz somente aquele registro para alteração, tornando o sistema muito mais leve e rápido. Tenho visto isso com muita freqüência no mercado.

Dependendo do sistema eu concordo em utilizar componentes não DataWare caso seja necessário navegar nos registros. Neste caso a atualização dos Edit´s teria que partir do programador, ou seja, utilizar talvez o evento onBeforeScroll do DataSet para então atualizar os controles em tela.

Cada caso é um caso, acredito que a melhor solução seja aquela que encaixa com a do seu cliente.

Olá amigos,

[b:c93045345f]Rafael[/b:c93045345f], acho interessante esse negócio de opiniões pois sempre aprendemos. No meu caso eu não acho o ideal ficar reconectando ao banco pois isso pode causar lentidão, mas é como sabiamente o [b:c93045345f]Adriano Santos[/b:c93045345f] mencionou, cada projeto tem sua cara e por isso sempre serão diferentes.

Eu prefiro carregar componentes na mão pois daí eu posso tratar tudo como for sem problemas. Centralizar tudo num Data Module eu não faço pois meu sistema trabalha com janelas não-modais. Desta forma e se o cara abre 2, 3 telas de cadastro de clientes (sim, isso é necessário!) como vou tratar? Por isso cada formulario tem seus DataSets e com isso não haverá conflitos e outros. Cada um ficaria ´em sua sessão´.

No meu sistema eu tenho um formulário padrão que é o pai de todos. Nele eu criei uma interface:



Como pode ver é mais trabalhoso mas pode ter certeza que, em minha opinião, a qualidade fica maior pois vc controla a interface como quiser.

Vlw!

[b:1788f5a08e]Romulo[/b:1788f5a08e], mais uma vez você está certo. Quando você, programador, se encarrega de desenvolver suas próprias rotinas, o controle é muito maior, porque você sabe o que o programa deve fazer, como, quando e porque. Porém, como você mesmo disse, é beeeem mais trabalhoso.

Quando estive em Sorocaba a uns anos atrás, num evento da ClubeDelphi, assisti uma palestra, não me lembro de quem, falando sobre ClientDataSet. O cara mostrou como criar uma boa tela de manutenção de dados. Cria-se uma tela onde o registro é pesquisado e enviado para outra janela; Esta janela será usada para o o usuário alterar ou simplesmente visualizar o registro. Achei show de bola, porque vc fica apenas com um registro aberto. Fica bem rápido.

Mas volto a dizer, cada caso necessita de um estudo diferenciado.

Olá!

Componentes data-aware são bons pois poupam o trabalho de se ter que exibir manualmente os dados do banco para o usuário. Da mesma forma que alguns controles implementam validações dependendo do tipo de dados. Por exemplo, um DBEdit não permitirá a digitação de letras em campos numéricos de uma tabela. Aliás, não de uma tabela, mas sim de um DataSet. E isso responde à pergunta do [b:823f623deb]Rômulo [/b:823f623deb]sobre se trabalhar conectado: os controles Data-aware não influenciam na conexão nem em transações. Vc pode exibir linhas de um arquivo texto local em um DBMemo, desde que vc o carregue para um DataSet. A tecnologia dbExpress é o melhor exemplo para se ilustrar isso.

Continuando sobre os componentes data-aware, eu não uso os que vem como Delphi. Prefiro usar de terceiros, que oferecem mais opções de controle e customização, ou então usar meus próprios, que fiz derivando direto de [b:823f623deb]TCustomEdit [/b:823f623deb]e implementando a classe [b:823f623deb]TDataLink[/b:823f623deb].

Talvez alguns usem um TEdit pq ele é menos amarrado do que um TDBEdit, mas acredito que seja só por isso. Em termos de performance, velocidade, etc, é praticamente a mesma coisa.

[]´s

Adriano,

Estes dias mesmo eu conversei com um programador Delphi amigo meu e ele como vem do Clipper (ainda vive dele até hoje, sistema de transportadoras) ele prefere este esquema de browse: uma tela com a lista de registros daí vc visualiza o registro e trabalha nele. Jà tentei fazer mas eu faço diferente. Com tenho cadastro de cliente. No campo codigo tem um botao que abre a pesquisa. Busco por nome, cpf, etc e depois exibo aquele registro somente. Por isso nao preciso de controles conectados.

Na mais pura verdade eu to usando Data Module e componentes a 3 semanas pois antes eu tava trabalhando totalmente Oo para atender a múltiplos bancos de dados usando Zeos. Eu tinha classe de conexão, interfaces para classes comuns.

Tipo eu tinha um Record de Cliente com os dados. Para incluir eu mandava no método o Record e a classe montava o SQL de acordo com o banco que eu estava trabalhando. Estava rodando legal, mas o desenvolvimento tava mais lento ainda (porém a manutenção era perfeita! Eu fazia tudo!) e como eu comecei a usar o FireBird e simplesmente fiquei impressionado então resolvi continuar com Zeos mas fazer com componentes pra agilizar. Depios vejo como faço pra atender o PostGreSQL.

Vlw!

romulo, vc tinha uma classe de conexao para trabalhar com o bd??
ha tempos atras eu postei um topico sobre isso, perguntando se era uma boa opcao utilizar - se dessa tecnica. Geral dos que responderam disseram que era atraso desenvolver algo assim pq ja tinha tudo pronto nos componentes, o que voce acha!?

Devo adimitir e voltar atrás no que disse :oops:, pois [b:8785355489]Michael[/b:8785355489] está certíssimo. A performance não é influenciada, lembrando que os dados já foram carregados localmente, pelo menos é o que se espera. :wink:

Só me intrometendo no assunto: :wink:

Eu utilizo DBEdits e etc.. e realmente não notei a diferença para os Edits normais (os quais eu utilizava), de certo com os edits eu tinha que manipular tudo, pegar campo por campo, verificar qual tinha sido alterado e manda junto com um UPDATE... realmente é muito, muito trabalhoso, porem você ganha no controle! Pensando nisso me veio uma pergunta muito pertinente: [b:48df802122]Tenho 25 DBEdits, vou la e altero somente 3 deles, quando dou um post ele altera so os 3 ou todos os 25?[/b:48df802122] Digo, ele cria um Update para todos ou so os que foram modificados? Se for para todos, com certeza pesa em performance.. nao eh?

[b:48df802122]Michael[/b:48df802122], eu também uso muito componentes de 3, justamente pelo que você citou, fiquei interessado.. quais você comumente usa? Pra Edits, DBGrid e etc...

Bem, aí está minha humilde opinião..

[]s a todos,

Rafael,

Eu fiz e eu não me arrependo, o meu problema foi prazo na entrega dos projetos. Se não fosse isso com certeza eu ainda estaria no meu modelo antigo. Eu tinha um Enum com o banco:



E tinha uma propriedade na classe TConexao que dizia qual banco estava sendo usado.

Daí nas Regras de negócio eu verificava o banco. Ex:



O funcionamento era mais ou menos assim. Se vc quiser eu te passo os fontes destas minhas classes pra vc avaliar, mas somente amanhã pois tá em casa.

Me manda um email pra romulocpd@yahoo.com.br que te envio.

Vlw.

Não é intromissão nenhuma [b:1e8d7fe9e8]titanius[/b:1e8d7fe9e8], podemos aprender juntos. :wink:



Você está usando o componete TUpdateSQL? Então ele vai ´alterar´ todos os campos sim, pois o que ele faz é criar uma sql com o comando UPDATE. Não acredito em perda de performance, já que o resultado seria o mesmo se você fizesse o update na mão tipo:



Me corrijam se estiver errado.



Também tenho intersse.

[]s a todos,[/quote:1e8d7fe9e8]

Eu sou da opinão do Romulo, acho que se você faz isso acaba centralizando mais as coisas. Se tiver problemas mais tarde basta corrigir as classes e recompilar os programas. No começo deve ser bem trabalhoso desenvolver, mas vale a pena.

Olá Titanius!

Quando se edita dados em um controle data-aware, o DataSet associado recebe as alterações, e é ele quem as propaga para o banco de dados, não os controles em si. No caso de uma conexão via dbExpress, então é o DataSetProvider quem vai gerar os UPDATES em SQL no banco. Sinceramente não sei se ele o DataSet é experto o suficiente para omitir os campos inalterados. Acho q não, pois como estão em memória, ele não tem como saber se no banco os dados ainda são os mesmos.

De qualquer forma, qualquer SGBD que se preze vai otimizar um UPDATE que altere campos para o mesmo valor, com certeza. Então incluir os campos inalterados no comando SQL não vai influenciar em nada, presumo eu. Duvido muito que um MSSQL da vida, ou mesmo o Firebird, vai acessar o disco para escrever o valor de um campo para ele mesmo. Gravar no disco é algo custeoso demais para se fazer inutilmente, e esses algoritmos são altamente complexos, e - pelo menos devem ser - eficientes.

Sobre os componentes, aqui na empresa usamos a suíte da DevExpress, que é boa, apresentando alguns bugs, mas nada até hoje que comprometesse o resultado final. Os Grid´s deles são sensacionais. Em casa trabalho num projeto usando os componentes da TMS para Intraweb, que facilitam demais o processo de desenvolvimento. E em um projeto anterior eu fiz por conta própria todos os componentes data-aware, derivados de TCustomEdit, e os implementei do jeito que quis. Em projetos mais simples usaria os db-aware nativos do Delphi mesmo, sem nenhuma dor na consciência. ;-)

[]´s

Oi Pessoal, Entrando no assunto de vcs.

Como eu comecei a programar em Java e estou a pouquíssimo tempo usando Delphi, eu gosto desse modelo de desenvolvimento.

Desenvolvir um FrameWorks básico, todo OO, nesse FrameWork eu tenho várias classes, uma para a conexão com o banco, outra para concultas e outras para Insert, Update e Delete.

Meu FrameWork usa Oracle, PostGree e FireBird, usando todos os recursos do BD,

por exemplo: se faço um Select limitando a quantidade de registros, no FireBird se usa [color=violet:bad8187d2c]first[/color:bad8187d2c] já no PostGreSQL se usa [color=violet:bad8187d2c]limit[/color:bad8187d2c]

A classe de consultas é responsavel por traduzir isso para cada BD suportado pelo FrameWork.

Como eu USO 100¬ OO, os Edits cairam como um luva pra mim.

Então, quanto a usar DBEdits e Edits, acho q isso depende muito do tipo de aplicação que vc deselvolve.

Se vc vai desenvolver um programa simples, único, com certeza Dbedits é a melhor solução, mais se vc quer padronizar, ou até mesmo criar uma ferramenta de produtividade como eu fiz, aí acho q vale a pena usar Edits e ter o controle da situação.

Já falei de mais... :D

[]´s

Independentemente do banco de dados usado, sempre se tem um DataSet para manter os registros, e então se pode usar controles data-aware. Quero dizer que usar TEdit´s, TComboBox, etc é uma opção do desenvolvedor, não uma imposição da situação.

A não ser, é claro, que se use buffers, packets, etc, no lugar de DataSets... ;-)

No concurso Uploader Master de 2004, eu ia escrever sobre como se criar uma suíte de controles data-aware personalizados, para não se depender os componentes nativos do Delphi e se ter mais flexibilidade. Bom, ainda bem que não escrevi na época ( :wink: ), mas acho que hoje não seria uma má idéia...

[]´s

Ah, esqueci de comentar mais uma coisa sobre o post da [b:3324ada659]Renata[/b:3324ada659]: frameworks OO são excepcionais. Meu amigo [b:3324ada659]Gustavo Chaurais[/b:3324ada659] e eu estamos preparando um artigo sobre o assunto para a revista ClubeDelphi. Acho q a comunidade irá apreciar...

[]´s

uhn, muito legal [b:bfacad6d29]Michael[/b:bfacad6d29] vcs abordarem esse assunto na revista, Uma boa idéia para a revista é FrameWorks para Client/Server e
Multi-tier usando OO, construindo um servidor de aplicação COM+ totalmente OO, isso seria muito legal.


[]´s

Esse tópico ficou bastante interessante mesmo, a dúvida sobre o uso ou não de componentes Data-Ware é muito grande mesmo, e como já foi dito aqui, cada caso é um caso, praticamente todos os aprendizes do Delphi utilizam componentes TDB... pq esses são vinculados ao DataSet, os programadores mais avançados optam por continuar com esses componentes ou buscam um controle maior sobre a aplicação e deixam de usar em boa parte ou na totalidade dos seus sistemas esse tipo de componente, alguns pensam q assim o seu projeto ficará melhor e as dores de cabeça serão menores quanto a corrupção de índeces, BD´s etc..., Eu já utilizei as duas formas, claro q utilizar componentes não Data-Ware dá muito mais trabalho apesar do controle, comparando performance não percebi diferença significativa alguma, tenho colegas q usam TEdit pq dizem q o TDBEdit deixa o DataSet aberto o tempo todo então é mais propenso a corrupção, outros falam q abrem e fecham o DataSet dependendo da situação, acredito realmente q isso tudo depende muito do objetivo a ser alcançado pelo Programador, depende da complexidade do sistema q ele está desenvolvendo e principalmente com a forma q ele (o programador) julga mais adequada.

Quanto ao FrameWork (esse papo é muito alto nível para meus dois neurônios), acho a idéia de se escrever um artigo sobre um FrameWork totalmente OO bem interessante, demonstrar ainda mais o poder da ferramenta e mostrar q desenvolvimento totalmente OO ou não é uma opção do programador, quem aprendeu desde de cedo a programar dessa forma, acredito q não pretendo deixar de usar o controle sobre os objetos.

[b:cca22e66e5]Michael e Gustavo Chaurais [/b:cca22e66e5] o artigo será uma mão na roda, hehe!!

Boa sorte!!!

Fica minha humilde opnião!!

Olá, pessoal!

Que assunto, hein?! Esse assunto é bastante recorrente em listas de discussão do Delphi e acho importante que todos opinem sobre ele, pois nunca haverá consenso, por isso todos podem se beneficiar de alguma forma com o desenrolar da discussão.

Eu sempre usei os componentes dataware nativos do Delphi, alguns deles com pequenas derivações para atender a comportamentos específicos. Definitivamente não há qualquer influência dessa utilização na performance do banco de dados, e também, principalmente após o advento do ClientDataSet, não há qualquer influência dessa utilização em qualquer problema de corrupção de índices ou qualquer outra anomalia no banco de dados. Os controle dataware, mantém-se vinculados a um único registro do banco de dados ou do cache local para exibí-lo ou editá-lo. Se você fizer um select que retorna um conjunto de dados (dataset) com 1.000 registros, irá demorar o mesmo tempo quer você utilize TDBEdits ou TEdits para exibir o registro atual para o usuário, pois os 1.000 registros já foram retornados. A demora também é a mesma nos dois casos (com ou sem dataware) se o select retornar apenas 1 registro. O que vai definir se você precisa retornar 1.000 registros para o usuário é ele próprio, o usuário e suas necessidades práticas. Claro que isso é só a minha opinião. Crio sistemas pensando nas necessidades do usuário, gosto de satisfazê-lo, pois se ele não estiver satisfeito com os sistemas que eu crio irá procurar outros.

Respondendo à dúvida do Michael Benford, no post de 10/01/06 às 12:20, SIM, o DataSetProvider é experto o suficiente para omitir os campos inalterados ao gerar os UPDATES. Raramente encontro alguém que já utilizou o método ´BeforeUpdateRecord´ para manipular as rotinas de atualização disparadas pelo DataSetProvider para cada registro incluído, alterado ou excluído no ClientDataSet vinculado a ele. Dá quase para fazer chover utilizando eventos como esse dos componentes de acesso a dados nativos do Delphi.

A propósito, vejo tanta gente falando em programar OO para acesso a dados (não só nesse tópico) e não consigo entender o que pode ser mais OO do que a framework criada pela equipe do Dephi para isso. O que pode ser mais OO do que as classes TDataSet, TField e TDB...? Com uns 10 cliques de mouse dá para fazer uma tela de cadastro sem uma linha de código sequer. Não vejo o que pode ser mais orientado a objetos do que isso. Lembrando... é a minha opinião.

Para encerrar só quero falar sobre o post do Romulo Oliveira de 10/01 às 9:25h sobre o uso de DataModule, onde ele afirma que não usa porque trabalha com janelas não-modais das quais podem ser abertas 2 ou 3 instâncias ao mesmo tempo. Esse fato não impede que você utilize DataModule, Romulo, pois você pode também criar uma instância nova do DataModule para cada formulário que o utiliza utilizando uma variável local ou privada do próprio formulário. Com relação à performance, o resultado é exatamente o mesmo de inserir os componentes de acesso a dados diretamente no formulário, sem falar que pensando em OO, o DataModule pode publicar propriedades e eventos próprios para tornar a interação com ele muito mais organizada e produtiva, mudando seu comportamento em função das necessidades do formulário que o está instanciando.

Ah, quase esqueci, sobre StoredProcedures eu queria só fazer uma observação: tenho algunas bancos de dados com muitas tabelas inter-relacionadas e não venho nenhuma vantagem em criar StoredProcedures para executar inclusões, alterações e exclusões em cada uma dessas tabelas. Uso muitas triggers para manter parte das regras de negócio do banco, e também uso muitas StoredProcedures executar ações e gerar relatórios complexos, mas não para incluir, alterar ou excluir.

Só estou expressando a minha opinião sobre os assuntos abordados neste tópico, sem qualquer ofensa, ok. Só quis dividir com vocês um pouco do que vem dando certo prá mim há alguns anos... e eu leio muuuuito antes de convencer a mim mesmo a adotar novas práticas. Esse talvez seja um bom conselho para qualquer desenvolvedor: escolham seus caminhos por vocês mesmos, pois vocês vão ter que se sustentar no caminho escolhido sozinhos.


Um abraço,
Jair Roberto Silva

Olá Jair,

Não havia pensado neste caso de uma variável local para o Data Module, muito boa, mas vou continuar meu projeto deste jeito pois além de me atender já tenho 30 fomrularios assim e nao quero mudar de repente.

Sobre as Storeds Procedures eu uso pois em algumas operações de Inclusão ou Alteração eu as vezes faços outrasoperações em outras tabelas e por isso quero aproveitar esta ´ida´ ao banco e já fazer tudo,pois trabalho com acesso remoto. Triggers me ajudariam sim, mas na Stored eu faço algumas operações que não seria legal por na trigger (em minha opinião).

Quando a este tópico acho realmente muito interessante todos opinarem pois cada um tem um jeito mas com certeza com as discussões agente aprende muito. Eu mesmo já repensei vários pontos do meu projeto com as discussões.

Um grande abraço pra galera ae!

JairRoberto? Quem é você?

Pow, tua óptica sobre o assunto é muito boa, gostei de ver. Não me lembro de tê-lo visto por aqui...rsrs...

Cara, não esquenta quanto a opnião/ofensa que aki não tem disso não. Todas as opinões são levadas em consideração. Por isso frequento a tanto tempo.

Forte abraço

Obs. Tô sentindo a falta do Massuda neste tópico, rsrs.

Beleza, Romulo! Conhecer alternativas sempre pode ser útil.

Sobre SP x Trigger, se você usa SP SEMPRE para incluir, alterar e excluir não vejo problema (eu não faria isso - hehehe). Mas eu penso que se, por exemplo, eu preciso incluir um registro na tabela ´B´ sempre que o valor do campo ´X´ da tabela ´A´ for incluído ou alterado para 5, prefiro usar uma Trigger para ter certeza de que isso ocorra sempre, do que ficar preso a usar uma SP sempre para incluir na tabela A, pois a minha memória nunca foi muito boa.

Um abraço,
Jair Roberto Silva

Falou-se muito nesse tópico sobre fazer as coisas quase que na unha, só pra manter controle sobre o que está acontecendo... Pois bem, é um ponto de vista, mas que pra mim não dá, pois normalmente o tempo que temos para desenvolver nossas aplicações é muito curto prá se dar ao luxo de ficar ´quase´ que reinventando a roda. Pôxa, o pessoal do Delphi é capaz, e os componentes DataWare são eficientes o bastante para a maioria das aplicações criadas com o Delphi.

Lendo a revista ClubeDelphi desse mês, que traz diversas abordagens sobre o Dephi2006, vejo as coisas estão cada vez em mais alto nivel, muitas formas de se desenvolver, muitas ferramentas, e ´pouca programação´ em si... É tanta novidade, que fica dificil assimilar...

Grande JairRoberto,

Realmente você está certo quanto as Triggers, mas é que na empresa que trabalho nós temos um esquema bem legal:

Temos um sistema em Cobol que roda a uns 10 anos. Estamos fazendo o sistema novo com SQL Server + VB6. Agora, como podemos fazer o sistema ser implantado, sendo que o Cobol nao pode sair de forma alguma?

Criamos triggers nas tabelas (cliente, fornecedor, produto,etc..) onde esta Trigger chama um objeto ActiveX (que nós criamos) que vai e atualiza os dados no cobol (inclusao, alteracao ou exclusão).

Uma coisa que percebemos aqui é que as vezes quando vamos fazer manutenção direto no banco, via SQL puro, sempre esquecemos de alguma ´trigger perigosa´ que pode ser muito ruim caso seja executada em lmilhoes de registros.

O unico motivo é este, eu sempre to no banco de dados mexendo direto entao se tiver Trigger pode ser perigoso alguma coisa. Por exemplo: digamos que no AFTER INSERT da tabela ITENS_PEDIDO_VENDA eu faço a movimentação de estoque. Pode um dia chegar o direto da empresa e falar pra fazer uma opração qualquer em todos os registros. Um exemplo real: Nós faziamos antes importação do Cobol pro SQL Server pra testes (hoje só exportamos via as triggers). Um cara q tava de ferias voltou e foi fazer a importação. Ele nao foi avisado (falha nossa!) que a trigger tava rodando. Simplesmente ele fez IO no Cobol 16 milhões de vezes pra importação.

Entendeu? As Triggers sao sim o melhor caminho, mas via Stored fico um pouco mais tranquilo por mexer direto na base, mas tenho muitas triggers tb. É caso a caso mesmo!

Vlw!!!

Muito interessantes as opiniões de todos a respeito do assunto. Graças a vocês cheguei a conclusão de que sou muuuito iniciante me Delphi e uma dúvida cruel me brotou na cabeça...
No sistema de uma padaria, criei uma tela de Controle de Compras 100¬ data-aware ligada a um Data Module. Bom, como já era de se esperar, esta é uma das telas mais usadas e que altera informações relativas ao estoque dos Produtos.
O problema é que também existe uma aplicação PDV, que também altera informações relativas ao estoque dos Produtos e isso está gerando alguns Lock Conflicts.
Meu colega de trabalho está recriando a tela, desta vez sem componentes data-aware, apenas edits e exibição e alteração de dados feitos manualmente.

Minha pergunta é: a troca de DBEdits por Edits resolve problemas de Lock Conflict?
Lock Conflict é realmente um problema comum quando se trabalha com componentes data-aware?

Perdoem minha ignorância. :P

Quando comecei a programar em Delphi, tinha uma culta de fazer tudo na mão, acreditando que ter o controle de todo o código era vantajoso. Com a experiência, vi que os componentes dataware são confiáveis e que a minha produtividade valia muito mais.

Antigamente eu conseguia ver algum ganho de performance utilizando Edit no lugar de DBEdit, hoje em dia, esse ganho é minimo (se existir). Sobre problemas de persistencia e locks, tem como resolver tudo isso nos coponentes dataware, basta configurá-los bem. O melhor pra isso é o DBExpress ou o BDP.

Valeu, Marcos Salex, não sei se meu camaradinha aqui vai aceitar, mas eu particularmente vou começar a adotar os componentes DBExpress e BDP.

O problema é exatamente essa ilusão de ganho de performance que o trabalho manual gera nas pessoas... Não existiria por acaso alguma ferramenta de medição de performance para softwares? Algum tipo de benchmark?

Olá a todos, também quero registrar minhas opiniões hehe!

Disseram lá para tras, não me recordo quem foi, que os controles DataAware não compromentem a performance ao se navegar por eles. Do jeito que eu trabalho não compromete mesmo, porque eu pego o dataset do meu banco, (IbDataset, Zeos ou o SqlDataset), conecto no dataset provider e uso tudo via clientdataset. Então, como os dados ficam no clientdataset desconectado, em memória, a performance é ótima.

Agora suponhamos que fizemos um select que traz 100 registros. Para o programador que usa clientdataset, é normal, transparente e rápido, agora e para aquele que usa os controles dbaware ligados diretamente no ibDataset, sem provider e sem client. Não fica lento navegar, deletar, editar etc... pelos 100 registros nesse caso? Ele não faria consultas sql ao banco de dados a cada operação? ou eu estou enganado?

Uma outra dúvida é a seguinte: muitas pessoas usam frameworks POO de persistencia, gui etc, tando proprios como de terceiros, mas continuam usando os compoentes dataaware, ligados a um clientdataset em memoria.

Funciona assim: a classe de persistencia dos dados copia ou clona os registros trazidos do ibdataset diretamente para o clientdataset, sem provider. Depois que os dados são alterados, manipulados etc, eles são copiados do client para o ibdataset, caso alterados, ou é gerada uma instrução de sql (insert, update, delete).. e é o dataset que faz o trabalho de gravar ou atualizar o banco.

Gostaria de saber até que ponto essa abordagem é válida.

Como existem infinitas formas de se fazer a mesma coisa, principalmente no delphi, que o número de ferramentas é muito grande, e como cada caso é um caso, então eu gostaria que nesse tópico, e qualquer outro que aborde esse assunto, cada um que falasse do seu sistema descrevesse brevemente como seu sistema é. Para nós podermos ter uma idéia do que é ´mais certo´ ou ´mais errado´, se é que existe um certo ou errado, de quando usar cada abordagem, por exemplo:

1) o seu sistema é desktop, cliente servidor, 3 camadas, n camadas, web ou terminal server?
2) você está adotando uma postura mais POO, mais POE (programação orientada a evento), Estilão RAD, usando uma ferramenta case ou tudo misto?
3) Qual o banco de dados?
4) pretende ser multibanco?
5) pretende ser cross-platform?

Eu acho que é isso. Para exemplificar, meu sistema:

1) cliente-servidor e roda em terminal server.
2) POE, num estilão conhecido do delphi, onde de vez em quando se usa alguma coisa de POO, mas pouco.
3) Firebird, com ibdataset, provider e clientdataset. (uso triggers e stored procedures)
4) Gostaria muito que fosse, por isso pretento até março trocar os ib** por uma classe minha que trabalhe com dbexpress.
5) Estaria querendo demais. Mas grande parte do meu sistema roda com wine :)

Espero não ter me delongado muito, mas esse é realmente um assunto de pesquisa atual meu, estou pesquisando bastante e testando frameworks, por isso gostaria de coletar todo tipo de informação a respeito.

[quote:e81deca415=´vitor^_^´]
Agora suponhamos que fizemos um select que traz 100 registros. Para o programador que usa clientdataset, é normal, transparente e rápido, agora e para aquele que usa os controles dbaware ligados diretamente no ibDataset, sem provider e sem client. Não fica lento navegar, deletar, editar etc... pelos 100 registros nesse caso? Ele não faria consultas sql ao banco de dados a cada operação? ou eu estou enganado?

[/quote:e81deca415]

Aqui eu uso o IBDataset, com acesso direto ao banco de dados... e uso DBEdit´s e variáveis de DBWare.... e não vejo diferença usando ClientDataSet... pelo menos em IBX o que você faz fica preso até você dar o commit...

Agora, você colocar um DBGrid e mandar trazer todos os dados de uma unica vez, e ficar passeando... o IBX é muito mais lento que o CDS... pelo motivo que você falou... ms como eu trabalho por parametros.. eu soh trago o registro que eu quero, entao não há diferença visível...


[]s

o titanius, e no caso dos like da vida?

o cara naum sabe mt bem o registro q quer trazer... como fica?

flw

bem aí qualquer um fica lento... na minha janela de pesquisa, tem a opção lá do like... porém ao clicar nesta opção é mostrado ao usuario que pode demorar... mas o normal é mesmo o igual...

Eu fiz besteira ao usar o IBX.. se eu fosse, hoje, começar outro projeto, [b:9c4c1f9614]certamente[/b:9c4c1f9614] usaria o DBExpress+CDS....


[]s

O IBX é bom se voce desenvolve para um cliente específico que vai ficar somente no Interbase/Firebird. Pra desenvolver pra vários clientes, é melhor o DBX caso necessite de um banco específico.

Isso já é um assunto bastante velho... Como o ´vitor^_^´ falou com ClientDataSet não há o menor problema, você não precisa deixar o Connection ligado sempre, só durante um bloco de requisições, ou seja, durante Opens ou ApplyUpdates. Após isso pode-se desconectar o Connection tranquilamente deixando o servidor totalmente livre.

E também não vejo porque do nada passar usar frameworks de persistência no Delphi. Pra mim Delphi virou quase um Clipper, é mais pra manutenção e avanços de projetos já implantados. Mas se o desenvolvedor já utilizava essa prática à tempo, tudo bem.

E sobre reinventar a roda criando frameworks proprietários não é uma boa prática, você acaba amarrando seu código fonte a uma tecnologia que não é usada no mercado. Caso uma empresa venha querer comprar o seu sistema pagando o valor do seu fonte, provavelmente não vai querer, pois grandes empresas não querem depender de uma única pessoa. Além de outras inúmeras desvantagens. A única vantagem é o total controle.

Lembrando que essa prática é mais eficiente utilizando conexão ADO, onde possui o recurso de pooling de conexões, não deixando lenta a reativação da conexão.

Bon Jovi, eu não entendi duas afirmações suas:
[quote:e5634e8829=´Bon Jovi´]
Pra mim Delphi virou quase um Clipper, é mais pra manutenção e avanços de projetos já implantados. Mas se o desenvolvedor já utilizava essa prática à tempo, tudo bem.
[/quote:e5634e8829]

e tambem, quanto a ....
[quote:e5634e8829=´Bon Jovi´]
E sobre reinventar a roda criando frameworks proprietários não é uma boa prática, você acaba amarrando seu código fonte a uma tecnologia que não é usada no mercado. Caso uma empresa venha querer comprar o seu sistema pagando o valor do seu fonte, provavelmente não vai querer, pois grandes empresas não querem depender de uma única pessoa. Além de outras inúmeras desvantagens. A única vantagem é o total controle
[/quote:e5634e8829]

Veja bem, isso não se aplica no caso de um framework open-source ou livre. E é vantajoso para a SUA empresa. De qualquer forma, eu conheço pucos frameworks do delphi. Eu sei que existe o ECO, mas que eu saiba, para delphi vcl32 ele só funciona no delphi 2006, ou nem isso, tem que ser .Net mesmo. E os open-source por enquanto não são tão completos assim.

Particularmente eu não gostaria de perder tempo aplicando novas tecnologias a uma tecnologia que está relativamente parada (Delphi Win32).


vitor^_^ escreveu:
Veja bem, isso não se aplica no caso de um framework open-source ou livre. E é vantajoso para a SUA empresa. De qualquer forma, eu conheço pucos frameworks do delphi. Eu sei que existe o ECO, mas que eu saiba, para delphi vcl32 ele só funciona no delphi 2006, ou nem isso, tem que ser .Net mesmo. E os open-source por enquanto não são tão completos assim.
[/quote:dc63619a4b](Só para ficar mais claro, aí estou falando não só do Delphi, mas de qualquer tecnologia de desenvolvimento).

Acho que não entendeu bem então o que escrevi, pois estou defendendo isso mesmo, utilizar algum framework largamente usado no mercado, que seja da própria ferramenta de desenvolvimento ou feito por comunidades open source. Mas não que seja feito do zero.

Agora eu entendi :) ... Eu não acho que o delphi win 32 esteja morto ou parado, principalmente por causa da comunidade, ma claro que isso é questão de opinião e interpretação. Todo mundo poderia ficar horas discutindo aqui sem chegar numa conclusão. E obviamete que tecnologias novas como .Net tem um futuro promissor.

Mas de qualquer jeito, quando uma ferramenta ou framework não existe ainda, ou não existe uma que atenda as suas necesidades, alguém, ou alguma comunidade, sempre tem que começar do zero. E é quase esse o caso de frameworks POO para o delhpi.

Pode não ser produtivo, com certeza não é, mas é divertido e pode ser um aprendizado gratificante. Muitas das tecnologias as quais pagamos pra usar hoje começaram assim.

Nao sei como anda a força do Delphi no mercado em relação a aplicação desses conceitos, mas pra esse caso onde ainda não há grandes opções, faz sentido mesmo.

[quote:ba099461c0=´Bon Jovi´]Nao sei como anda a força do Delphi no mercado em relação a aplicação desses conceitos, mas pra esse caso onde ainda não há grandes opções, faz sentido mesmo.[/quote:ba099461c0]

A impressão que eu tenho é de que o Delphi está passando por uma fase de transição, e nem a Borland ainda não definiu direito seu rumo.