Fórum DataWare ou Edits? #308510
10/01/2006
0
alguém poderia fazer um breve resumo sobre as características dos dois?
quais os prós e os contras de cada um?
quais vc´s preferem utilizar? pq?
quais os prós e os contras de cada um?
quais vc´s preferem utilizar? pq?
Raserafim
Curtir tópico
+ 1
Responder
Post mais votado
10/01/2006
sim sim, sempre tive essa duvida tbm ... :roll:
Rafael Gomes
Responder
Gostei + 1
Mais Posts
10/01/2006
Romulocpd
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!
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!
Responder
Gostei + 0
10/01/2006
Rafael Gomes
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
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
Responder
Gostei + 0
10/01/2006
Adriano Santos
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.
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.
Responder
Gostei + 0
10/01/2006
Romulocpd
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: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:
type IFormularioCadastro = interface procedure IniciarEdicao; procedure FinalizarEdicao; procedure CarregarCampos; procedure LimparCampos; end;
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!
Responder
Gostei + 0
10/01/2006
Adriano Santos
Olá amigos,
[b:1788f5a08e]Rafael[/b:1788f5a08e], 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:1788f5a08e]Adriano Santos[/b:1788f5a08e] 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!
type IFormularioCadastro = interface procedure IniciarEdicao; procedure FinalizarEdicao; procedure CarregarCampos; procedure LimparCampos; end;
[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.
Responder
Gostei + 0
10/01/2006
Michael
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
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
Responder
Gostei + 0
10/01/2006
Romulocpd
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!
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!
Responder
Gostei + 0
10/01/2006
Rafael Gomes
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!?
Responder
Gostei + 0
10/01/2006
Adriano Santos
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:8785355489]Rômulo [/b:8785355489]sobre se trabalhar conectado: [color=red:8785355489][b:8785355489]os controles Data-aware não influenciam na conexão nem em transações.[/b:8785355489][/color:8785355489] 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.
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:
Responder
Gostei + 0
10/01/2006
Titanius
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,
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,
Responder
Gostei + 0
10/01/2006
Romulocpd
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.
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:
type EnuBancosAtendidos = {baMySQL, baPostGreSQL, baFireBirdSQL};
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:
procedure RetornarTitulosPorClientePorMeses(pCliente: Integer, var pRS: TZQuery);
var
SQL: String;
begin
if FConexao.BancoDeDados = baFireBirdSQL then
SQL := ´SELECT ...´
else if FConexao.BancoDeDados = baMySQL then
SQL :=- ´SELECT...´
end;
end;
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.
Responder
Gostei + 0
10/01/2006
Adriano Santos
Só me intrometendo no assunto: :wink:
Não é intromissão nenhuma [b:1e8d7fe9e8]titanius[/b:1e8d7fe9e8], podemos aprender juntos. :wink:
[b:1e8d7fe9e8]Tenho 25 DBEdits, vou la e altero somente 3 deles, quando dou um post ele altera so os 3 ou todos os 25?[/b:1e8d7fe9e8] Digo, ele cria um Update para todos ou so os que foram modificados? Se for para todos, com certeza pesa em performance.. nao eh?
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:
UPDATE TABELA SET CAMPO1=EDIT1, CAMPO2=EDIT2, CAMPO3=EDIT3 WHERE ....
Me corrijam se estiver errado.
[quote:1e8d7fe9e8]
[b:1e8d7fe9e8]Michael[/b:1e8d7fe9e8], eu também uso muito componentes de 3, justamente pelo que você citou, fiquei interessado.. quais você comumente usa? Pra Edits, DBGrid e etc...
Também tenho intersse.
[]s a todos,[/quote:1e8d7fe9e8]
Responder
Gostei + 0
10/01/2006
Adriano Santos
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:
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.
Responder
Gostei + 0
10/01/2006
Michael
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
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
Responder
Gostei + 0
10/01/2006
Renatacoimbra
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
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
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)