Jump to content

Firedac


Kline777
 Share

Recommended Posts

Como prometido num tópico recente, queria só deixar umas luzes sobre o que já vi do Firedac. Pode ser interessante para voces.

Eu tenho usado o Firedac nos ultimos meses e até agora as vantagens que tenho visto sao:

  • Velocidade. É notoriamente mais rapido que os DbExpress e os Ado em todos os cenarios. Tambem permite um modo Livewindow que quando queremos apenas LISTAR dados de uma tabela que o torna ainda mais rapido que tudo o resto.
  • Compatibilidade.Traz já conectores para os servidores de base de dados mais usados e que não funcionavam com os outros sistemas. MySql,PostGres, Sqlite etc... e permite usar alguns truques nas querys para que se possa usar funçoes genericas nao dependentes do motor de base de dados onde estamos a trabalhar, para que seja possivel a mudança de servidor sem grandes/nenhumas alterações ás instruçoes SQL das querys.
  • CachedUpdates: O funcionamento base de um dataset no delphi é que cada vez que se muda de registo no dataset ou se chama um post ele escreve na BD os dados desse registo (Penso que nao estou a dizer asneira). Com os cached updates podemos impedir que ele faça isto constantemente e escolher o momento onde os dados vao para a BD. Se eu quiser correr o dataset do inicio ao fim para mudar um dado campo posso usar isto para que ele só actualize a info na BD quando terminarmos de editar todas as linhas que nos interessem. Evita N idas á BD quando queremos actualizar info em bloco.
  • Arrays de parametros: Esta acaba por ser para o mesmo fim que a anterior. Exemplo: Temos uma query para inserir uma linha numa tabela e esta query tem o parametro @Nome que precisa de receber.Se quisermos inserir 10 registos temos de preencher o parametro 10 vezes e chamar o ExecSql da query em cada uma delas.O que o firedac permite é dizermos quantas linhas queremos inserir (neste caso 10) e o parametro que a query espera agora nao é uma string mas sim um array de 10 strings. Preenchemos a info num loop e chamamos o ExecSQL UMA unica vez. Ele trata de replicar a query 10 vezes com os diferentes parametros.
  • Local SQL: Este nunca usei mas basicamente é a posibilidade de usar instruçoes SQL numa memorytable(Nao sei se usam isto, eu sou adepto... para guardar configuraçoes de sistema ou tudo o que seja dados que tenham de ser gravados em ficheiros)

Nota: Eu sei que muitos de voces usam SQL construido no codigo o que faz com que a utilidade de algumas das funções seja perto de nula. Mas por acaso nao gosto de fazer isso portanto tenho usado muitas destas funcionalidades para ter SQL apenas nas Querys e Datasets e nunca no codigo.

  • Vote 1
Link to comment
Share on other sites

Acho que independentemente do local onde se usa o SQL, isto trás vantagens...

hmmmmm

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Link to comment
Share on other sites

Thanks for the Post Kline 🙂

Temos algum componente tipo QueryUpdate ? tipo Zupdate(Zeos) ?

(...)

Nota: Eu sei que muitos de voces usam SQL construido no codigo o que faz com que a utilidade de algumas das funções seja perto de nula. Mas por acaso nao gosto de fazer isso portanto tenho usado muitas destas funcionalidades para ter SQL apenas nas Querys e Datasets e nunca no codigo.

Pois eu acho, que tanto um como outro tem vantagens e desvantagens, eu utilizo os 2 conforme a situção, mas irónicamente estou com um "problemão" por utilizar Sql no código 😕

As mentes humanas são realmente um local estranho!

Link to comment
Share on other sites

Eu não conheço NADA do Zeos mas no Firedac existe um TadUpdate que suponho que seja igual.

Tambem é algo que nao existe na DBExpress e ADO que também gosto. Ao inicio embirrei com o componente mas já me rendi.

O que ele faz é criar/editar os scripts necessarios para Ler/escrever/editar/apagar um registo e associar este componente a um dataset qualquer.

Ou seja, permite-nos ver/alterar o que acontece quando fazemos Post/edit/delete no dataset. Uso muito disto quando faço querys a mais que uma tabela e preciso que ele faça update a mais que uma tabela, ou quando preciso de inserir registos em mais que uma tabela quando faço um simples append.

Mais uma vez, permite controlar todo o SQL chamado pelos datasets sem ter de estar no codigo.

Não sei se era a isto que te referias 🙂

  • Vote 1
Link to comment
Share on other sites

(...)

Não sei se era a isto que te referias 🙂

É isso mesmo amigo 😄 é a chave para problemão que tenho, o outro pequeno problema é que tenho centenas de milhares de Linhas de Código, entre as quais, SQL fora dos componentes 🙂 é nesta altura que vou chorar lol

As mentes humanas são realmente um local estranho!

Link to comment
Share on other sites

Pois eu acho, que tanto um como outro tem vantagens e desvantagens, eu utilizo os 2 conforme a situção, mas irónicamente estou com um "problemão" por utilizar Sql no código 😕

Bem, penso que quando se referem a SQL nas querys, estão a falar de meter a instrução SQL directamente no componente, em DesignTime, certo?

Se é isso, nem uma tenho assim... Nos ZSQLUpdate's sim, mas em querys não.

Passo a explicar.

É algo que comecei a implementar apenas no software de POS que ando a fazer, e parece-me que está a dar certo.

O código SQL todo directo nos componentes não me serve, na minha forma de trabalhar. As querys são dinâmicas e fazem muitas vezes vários papeis, dependendo de onde estão a ser usadas. Inclusivamente, falando em querys dinâmicas, há muitas que crio em runtime.

Como faço então para gerir o SQL?

Tenho no programa uma unit, chamada uQuerys.pas, onde estão contidas todas as querys do programa, numa classe genérica, só com funções que retornam strings.

Cada função, é uma query, mas pode ser subdividida, mediante parametros, caso tal se justifique.

Por exemplo:

type
   TQuery=Class
   Public
     function ListaContadores(Inactivos:Boolean):String;
     function ListaDocumentos(FullInfo:Boolean):String;
   end;

implementation

function TQuery.ListaContadores(Inactivos:Boolean):String;
begin
  Result:='SELECT * FROM Counters ';
  if not Inactivos
     then Result:=Result+'WHERE Activo=1 ';
end;

function TQuery.ListaDocumentos(FullInfo:Boolean):String;
begin
  Result:='SELECT * FROM Documentos';
  if FullInfo
     then Result:=Result+'INNER JOIN Counters ON Counters.CounterID = Documentos.CounterID ';
end;

Vantagens disto:

- Muitas vezes, em zonas diferentes do programa, preciso em querys diferentes dos mesmos dados. Com isto, basta-me chamar para ambas a mesma função.

- Tenho tudo reunido. Qualquer alteração, está ali, é lá que tenho de mexer. Pode estar no meio de centenas... Mas está lá. E se estiverem bem comentadas, as funções explicam-se a si mesmas, e é fácil lá chegar

- Código mais limpo. Quando executo uma query, faço algo tipo "qEmpregados.RunSql(Query.ListaEmpregados);", e não preciso meter statements SQL no meio do código Delphi.

Há outra vantagem, que foi o que me levou a começar este sistema.

Se quiser ter o meu programa preparado para mais que um motor de base de dados, e sem as facilidades do FireDac, está visto, eu ia ter de andar com if's ou case's no meio do código, e meter varios statements para uma só query, quando o idioma SQL não for igual.

Então o que faço aqui?

Criei uma função, ServerType, que me verifica, quando necessário, qual o tipo de SQL que está a ser executado. Nada de especial, apenas verifica o protocolo a ser usado pela ligação ZConnection naquele momento.

function TQuery.ListaAcessos(EmpregadoID:Byte):String;
begin
    case ServerType of
         stMySQL:Result:='SELECT *, ConCat(EmpregadoID,"-",Codigo) AS UniqueKey, Cast(LPad(Acesso,char_Length(Acesso)+char_Length(Codigo)-2," ") AS CHAR(60)) AS AcessoPad '+
                         'FROM Acessos WHERE EmpregadoID = 0'+IntToStr(EmpregadoID)+' ORDER BY Codigo';
         stMSSQL:Result:='SELECT *, ConCat(EmpregadoID,''-'',Codigo) AS UniqueKey, (REPLICATE('' '',Len(Codigo)-2)+Acesso) AS AcessoPad '+
                         'FROM Acessos WHERE EmpregadoID = 0'+IntToStr(EmpregadoID)+' ORDER BY Codigo';
         stSQLite:Result:='SELECT *, (EmpregadoID || "-" || Codigo) AS UniqueKey, Acesso AS AcessoPad '+
                          'FROM Acessos WHERE EmpregadoID = 0'+IntToStr(EmpregadoID)+' ORDER BY Codigo';
    end;
end;

Claro que com o Firedac, pelo que me estão a dizer, e pelo que já li, isto seria desnecessário. Com os devidos ajustes, a query poderia ser a mesma para os vários casos...

  • Vote 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Link to comment
Share on other sites

(...)

Claro que com o Firedac, pelo que me estão a dizer, e pelo que já li, isto seria desnecessário. Com os devidos ajustes, a query poderia ser a mesma para os vários casos...

Certo Nuno, eu concordo, até acho a tua questão da unidade com as instruções SQL lá dentro bastante interessante, claro que se for numa Listagem mais complexa torna-se mais complicado, por exemplo, numa das minhas Listagens de Documentos emitidos a Instrução começa com 2 linhas, e mediante o quadro de opções que é mostrado ao Cliente pode terminar com 30 ou 40 linhas.

Mas continuo a achar que ambas fazem sentido, eu até sou adepto de fazer as coisas em Run-time por ocupar menos recursos, por ser mais rapido de alterar porque não estamos dependentes de dispobilidade de componentes, mas por exemplo trabalhar com 1 Dbgrid que Lê de um servidor e escreve noutro, é impossível ser em Run-time, oxalá não fosse que eu resolvia o meu problema 😄

O problema que eu tenho aqui, o Kline nunca o vai ter 🙂 por isso é que eu digo que ambas têm vantagens e desvantagens 🙂

http://www.portugal-a-programar.pt/topic/65581-balanceamento-de-carga-delphi-mysql-saas/

Edited by CrominhO

As mentes humanas são realmente um local estranho!

Link to comment
Share on other sites

Sem dúvida, todos os nossos hábitos e crenças de programação estarão sempre em causa, e haverá situações em que teremos de as trocar por outros métodos que na altura certa se apresentem melhores para resolver um determinado problema...

Um bom programador é como um camaleão... 😛

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Link to comment
Share on other sites

Tenho usado os componentes da devart (DAC) pela simplicidade (Aplicação->DB), sem dlls, e pela rapidez.

Tentei usar o firedac mas dava-me sempre erro mesmo com a dll (no caso, libmysql.dll) quer na pasta windows, system32 ou mesmo junto ao executável.

Link to comment
Share on other sites

Pois... tens de ter o Mysql client instalado e dizer-lhe o caminho do driver.

Já consegui. Era o problema dos 64bits.

Tenho o mysql x64 e estava a usar a libmysql.dll correspondente e o firedac só funciona com a libmysql.dll de 32bits.

Link to comment
Share on other sites

Tenho o mysql x64 e estava a usar a libmysql.dll correspondente e o firedac só funciona com a libmysql.dll de 32bits.

Possivelmente o FireDAC funciona com a dll a 64 bits se estiveres a compilar para 64 bits.

Estando a compilar para 32 bits, mesmo que o SO seja a 64, precisas da dll de 32.

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.