ClubeDelphi

Paradox X InterBase
Introduo

www.clubedelphi.com.br

A primeira vista, as tabelas Paradox no apresentam muitas diferenas das tabelas criadas no InterBase e as seguintes semelhanas so evidentes: acesso pode ser feito atravs de um Alias; os tipos dos campos possveis so similares, apesar de possurem nomes diferentes; as tabelas podem ser criadas com o DataBase Desktop ; so utilizados os mesmos componentes TTable e TQuery para acesso; Na realidade, o BDE (Borland DataBase Engine) cria uma iluso de que tabelas InterBase e Paradox comportam-se da mesma maneira. Para alguns desenvolvedores, entretanto esta iluso termina logo. A primeira decepo vem com a utilizao do Database Desktop para manipulao de tabelas InterBase. Enquanto o Database Desktop a ferramenta ideal para criao e restruturao de tabelas Paradox, deficiente com relao ao Interbase, onde a restruturao e a utilizao de caractersticas mais avanadas s podem ser alcanadas atravs da montagem de scripts que sero executados no Interbase Windows ISQL. As pesquisas e ndices no InterBase diferenciam maisculas e minsculas, enquanto que no Paradox esta diferenciao configurvel. Ainda no InterBase a definio de chaves primrias e estrangeiras realizada facilmente, porm a alterao destas chaves no to trivial. Algumas operaes utilizando o InterBase so mais lentas do que no Paradox. Torna-se rapidamente claro que o InterBase no automaticamente melhor que o Paradox. A idia de que o InterBase no sempre mais adequado do que o Paradox verdica. Os dois produtos apresentam diferenas significativas e a escolha de qual utilizar plenamente dependente das condies e dos objetivos do aplicativo final. Na realidade, a nica coisa que eles tem em comum que ambos armazenam dados em tabelas. Cada um possui pontos fortes e fracos dependendo da realidade a ser trabalhada. O importante decidir qual deles apropriado para uma situao particular. A deciso tomada, usar Paradox ou InterBase, afetar de forma significativa o desenvolvimento do seu projeto.

Paradox: Baseado em Arquivos

O Paradox um sistema de banco de dados baseado em arquivos. Os arquivos de dados contm registros de dados que possuem uma ordem fixa. Em outras palavras, o registro de nmero 106 ser sempre o mesmo registro, at que seja movido fisicamente dentro do arquivo, atravs de uma operao de ordenao, por exemplo. O que mais importante, ele ser sempre o sucessor do registro 105 e o antecessor do 107, at que esta ordem seja explicitamente alterada. Isto permite uma fcil navegao entre os registros, atravs do cursor, j que possvel localizar um registro em uma tabela atravs da sua posio, sem necessidade de referenciar seu contedo. Esta ordenao explcita de registros em uma tabela, apresenta algumas vantagens: a movimentao para o incio ou para o final de um arquivo de dados simples e os registros podem ser facilmente relidos quando um cursor posicionado sobre eles. A concepo de navegao (browsing) pode ser conveniente para usurios e desenvolvedores. Isto permite que os registros sejam manipulados um de cada vez e em uma ordem previsvel. Este comportamento de navegao nas tabelas Paradox uma das caractersticas mais difceis de serem adaptadas ao sistema InterBase, e muitos desenvolvedores em InterBase tm grandes problemas em efetuar esta transio.

InterBase: Baseado em Conjuntos

O InterBase na realidade um sistema de banco de dados relacional. As tabelas no so armazenadas em arquivos individuais e o que mais interessante: os registros no encontram-se ordenados. Matematicamente falando, os conjuntos so desordenados. A ordem descoberta somente quando o conjunto for representado, como por exemplo em uma consulta ao banco de dados. Voc no pode contar duas vezes com o fato de o mesmo registro ser o registro nmero 105, a menos que explicitamente seja imposta uma certa ordenao na consulta. Uma vez que no podemos identificar positivamente um registro pela sua posio dentro de uma tabela devemos nos referir a valores internos a este registro. Entretanto, para identificaes positivas de um registro, pelo menos um campo ou a combinao de alguns campos devem conter um valor nico para cada registro, o que conhecido por Chave Primria.

 possvel que mais de um campo ou combinaes de campos possam fornecer valores nicos. Estes campos - ou combinaes - so denominados Chaves Candidatas. imprescindvel para o gerenciamento de um sistema de banco de dados a identificao de Chaves Primrias. Uma tabela que possui uma Chave Primria chamada de R-table e todos os Data Sets (tables, query e stored-procedures) devem ser R-tables para que o modelo relacional possa funcionar corretamente. A vantagem deste conceito de dados baseado em conjunto que os conjuntos e as operaes neles realizadas possuem a propriedade de encapsulamento. Isto significa que quando realizamos operaes em um conjunto sempre geraremos um outro conjunto, que poder, ento, ter uma nova operao com ele realizada, produzindo um novo conjunto, e assim suscessivamente. Este um poderoso conceito lgico que, se corretamente implementado, tornar o desenvolvimento de aplicaes independente das caractersticas fsicas de armazenamento. Esta a base dos modelos relacionais. Os sistemas baseados em cursor (cursor-based) como o Paradox permitem que voc trabalhe somente com um registro de cada vez. Sistemas baseados em conjuntos (set-based) permitem a manipulao de conjuntos de dados como se fossem uma entidade nica. Esta caracterstica permite a simplificao do desenvolvimento de aplicaes, alm de melhor garantir a integridade dos dados.

Projetos Fsicos e os Impactos de Velocidade

O Paradox um sistema-cliente no qual os dados so completamente manipulados por clientes individuais. Quando voc quiser que os dados sejam lidos ou manipulados, eles devem ser transportados para a aplicao. Cada aplicao manipula todo o processamento por si s. Se mltiplos usurios estiverem acessando a tabela simultaneamente sobre uma rede, cada aplicao usuria transporta os dados requeridos para a mquina usuria. Cada instncia de aplicao Paradox no tem retorno de outra. Se uma instncia precisa garantir a estabilidade dos dados por alguma razo, ela deve proibir outras instncias de alterarem os dados atravs de um esquema de travamento (locking scheme). Quando, em uma aplicao Paradox, precisamos procurar em uma tabela, a seguinte rotina ser efetuada: (1) os dados brutos e ndices necessrios devem ser carregados na memria da mquina cliente; (2) a atividade fsica da procura conduzida; (3) os resultados so gerados; e (4) os dados tornados desnecessrios aps a operao so ento descartados. Esta rotina repetida para cada operao sobre cada cliente. O servidor de arquivos que contem os arquivos de dados no faz nada alm de enviar os dados brutos requeridos, atravs da rede, para as mquinas clientes, sem realizar quaisquer esforos de processamento dos dados. Funciona, assim, como um disco rgido remoto. Em suma, o Paradox veloz em um disco rgido local mas a sua performance diminui drasticamente em uma rede. A rede fica sobrecarregada, com um grande volume de processamentos sendo realizados repetidamente na mquina cliente. Mesmo em uma rede pequena a performance rapidamente afetada quando um novo usurio conectado. O InterBase um sistema baseado em servidores (server based). Em vez de diferentes processos manipulando fisicamente os dados armazenados, somente um processo central, rodando na mquina servidora, possui acesso direto aos dados. Todas as aplicaes clientes desenvolvem polticas de requerimento ao processo servidor, o qual processado diretamente na mquina servidora enquanto o cliente aguarda. Quando o servidor termina ele transmite apenas os resultados de volta ao cliente, que retoma ento suas atividades. O impacto mais direto deste esquema que a rede no necessita ficar congestionada com grandes volumes de dados redundantes sendo enviados pelos clientes. Alem disso, as tarefas frequentemente complexas de processamento de dados podem ser delegadas de mquinas clientes, normalmente menos poderosas, para as normalmente mais poderosas mquinas servidoras. Deve-se perceber que tudo sobre o desenvolvimento em InterBase implica em um ambiente multi-usurio. O InterBase foi desenvolvido desde o princpio como um sistema multi-usurio. O Paradox, por outro lado, foi basicamente desenvolvido para um nico usurio, sendo que caractersticas que visavam permitir o atendimento a mltiplos usurios foram depois sendo adicionadas.

InterBase No Para Navegao

Conforme foi mencionado anteriormente o InterBase constitui-se em um verdadeiro RDBMS (Sistema Relacional de Gerenciamento de Banco de Dados) mas a performance de algumas operaes so realmente mais lentas do que em tabelas Paradox. Esta questo tornase evidente quando temos uma tabela com uma quantidade muito grande de registros. Se voc utilizar o mtodo Last com o objetivo de mover o ponteiro para o ltimo registro da tabela certamente perceber uma grande diferena na performance dos dois sistemas. Portanto, para estas operaes, a utilizao de tabelas Paradox torna a aplicao mais veloz do que em tabelas InterBase. Em tabelas Paradox o ndice aponta para um endereo fsico onde se encontra o registro. O cursor na tabela Paradox mover quase que instantaneamente para a posio determinada porque ele conhece a localizao fsica (endereo) deste registro na tabela. Esta operao na tabela InterBase poder apresentar alguns problemas. Primeiro porque os dados encontram-se desordenados e existe uma questo sobre o que constitui o ltimo. A operao deve impor uma ordem antes de decidir qual registro o ltimo. Por default o ltimo registro ser considerado aquele registro cuja Chave Primria possui o maior valor.

Portanto, necessrio determinar o valor da maior Chave Primria. Uma vez que este valor foi determinado o registro que possui este valor pode ser recuperado. Se for necessrio recuperar os ltimos registros (como no caso da apresentao dos dados em um grid) o processo deve ser repetido algumas vezes, tornando-se um pouco complicado. Para recuperar o penltimo registro, o InterBase deve agora encontrar o maior valor da chave primria que seja inferior ao valor mximo desta. Para o antepenltimo registro, ele deve procurar o valor mais prximo ao mais prximo do valor mximo da chave primria, e assim consecutivamente, at o nmero necessrio de registros ser recuperado. Uma operao que uma moleza para o Paradox torna-se uma tremenda dor-de-cabea para o InterBase. Em geral, a navegao de trs para frente atravs de tabelas SQL ineficiente. O BDE armazena grupos de registros para minimizar este problema, mas se voc avanar muito para trs em tabelas relativamente extensas, acabar tendo que aguardar por pausas significativas.

Travamento (locking)
Quando dois usurios tentam acessar a mesma faixa de dados podem surgir problemas ameaando a integridade do banco de dados. O Paradox e o InterBase lidam com estes problemas de maneiras diferentes. Como o Paradox no possui nenhum conhecimento do que outro processo Paradox est fazendo, ele utiliza um esquema pessimista de travamento (Pessimistic Locking Scheme). Assim que um usurio tenta mudar um registro o registro travado. Nenhum outro usurio pode fazer alteraes neste registro at que o primeiro usurio termine as alteraes ou cancele a operao. Por um lado, este esquema de travamento positivo se considerarmos que o usurio que obteve o travamento poder concluir com sucesso a sua operao de alterao. Por outro lado, isto negativo no sentido em que um usurio poder monopolizar um registro indefinidamente. Isto seria um problema, por exemplo, num sistema de reserva de viagens. Um viajante indeciso poderia trancar um assento por um longo perodo, levando os outros a acreditarem que assento j foi tomado, sendo que no final o indeciso pode acabar desistindo do assento. O InterBase, por outro lado, lida com a manipulao de todos os dados atravs de um esquema de concorrncia otimista (Optimistic Concurrency Scheme). Na verdade, quando um usurio processa uma alterao o registro no impedir que outras pessoas tentem tambm alterar este registro. Quando um usurio comea a alterar um registro InterBase uma cpia do registro original salva. O usurio executa seu servio, mas os outros usurios no esto sob nenhuma forma impedidos de acessar o mesmo registro. Quando algum usurio termina sua alterao e efetua um post (atualizao no banco) a cpia do registro original comparada com o registro corrente. Se os valores so diferentes (provavelmente porque outro usurio alterou mais rapidamente o mesmo registro) as alteraes efetuadas pelo usurio no registro so rejeitadas. Isto significa que usurios individuais no podem travar o acesso de outros usurios ao mesmo registro. No exemplo anterior de reservas de viagens, o primeiro passageiro a confirmar a reserva ficaria com o lugar, mesmo se vrios outros usurios estivessem simultaneamente considerando o mesmo lugar. O lado ruim da estria, porm, que as alteraes so rejeitadas apenas no momento em que se tenta efetuar a atualizao no banco, aps todo o trabalho de alterao ter sido efetivado. Isto pode ser corrigido relendose (pelo mtodo refresh) os campos alterados e tentando-se novamente efetuar a atualizao. Os componentes TTable ou TQuery tornam esta operao transparente atravs da propriedade UpdateMode. A verificao, quando enviamos comando de atualizao no banco, pode ser feita dependendo do valor desta propriedade, em todos as campos, somente nos campos alterados ou somente nas chaves primrias. Estas duas vises refletem as diferenas bsicas nas duas filosofias. O modelo pessimista Paradox assume que as colises sero frequentes e devero ser tratadas de uma forma rigorosa, enquanto o modelo otimista InterBase assume que as colises sero ocasionais e maximiza a habilitao dos usurios para o compartilhamento de dados sem interferncia de um com o outro, enquanto estiver sendo mantida a integridade. Um importante benefcio do modelo do InterBase que um usurio que quer visualizar um conjunto de dados estveis, talvez para gerar uma srie de relatrios que precisam refletir a situao atual dos dados, no sofrer interferncia de outro usurio que estiver naquele momento alterando os dados. Em tabelas Paradox, o gerador de relatrios dever colocar um write lock na tabela para garantir que os dados no sejam alterados e ningum poder efetuar transaes na tabela at que este lock tenha deixado de existir. No InterBase as verses dos registros mais antigos, so retidas durante o tempo em que o usurio estiver algum interesse sobre elas. Isto significa que nem os leitores dos dados impedem a ao dos editores e nem os ltimos comprometem o resultado dos primeiros. InterBase o nico banco SQL que torna isto transparente. Quando os adeptos do InterBase so questionados sobre as vantagens do banco, este controle da disponibilidade do registro normalmente a primeira vantagem a ser mencionada.

Processamento de Transaes
Como voc j sabe, o modelo baseado em conjuntos constitui-se em um conjunto de dados que podem ser tratados como entidades individuais, levando em considerao o contedo especfico destes conjuntos. O processamento de transaes uma extenso destas idias. Uma transao um grupo de operaes onde ou todas elas so bem ou mal sucedidas. Nunca dever ocorrer a situao onde apenas algumas sejam bem ou mal sucedidas.

Por exemplo, um caixa automtico realiza transaes com bancos de dados. Sempre que voc retira dinheiro, duas operaes devem ser realizadas para que o banco possa contabilizar seu ativo apropriadamente: o saldo da sua conta deve ser reduzido e o saldo de dinheiro disponvel no banco deve ser reduzido na mesma quantia. Obviamente, a situao prefervel aquela na qual as duas operaes sejam bem sucedidas, mas se acabar a energia no meio de uma operao, totalmente inaceitvel que uma conta seja atualizada e a outra no - ambas operaes deveriam falhar para manter uma contabilizao apropriada. O processamento de transaes permite que isto acontea. As operaes em uma transao no so permanentes at que seja efetuado o commit na transao. At que isto acontea, as operaes podem ser desfeitas, retornando-se ao ponto de partida. Um Rollback pode ser implementado explicitamente, utilizando-se o mtodo Rollback, ou automaticamente, quando ocorre uma falha do sistema. O InterBase suporta totalmente o conceito de transaes. Na realidade, todas as operaes ocorrem dentro de um contexto de transao. Na ausncia de um controle explcito do programador, o BDE automaticamente envolve todas as operaes na sua prpria transao. Por exemplo, toda vez que voc atualiza um registro, a transao inicializada (started) e finalizada (commited) automaticamente aps cada confirmao (post). Usando o componente TDataBase voc pode explicitamente controlar uma nica transao, e tambm faz-la conter quantas operaes voc quiser. O Paradox porm no suporta transaes. Sempre que um registro atualizado no banco, as mudanas so permanentemente gravadas na tabela. Ser necessria uma nova alterao para desfazer manualmente as alteraes anteriores se um Rollback for desejado. Alm disto, o sistema no ir garantir que, em um grupo de operaes, todas elas sero bem sucedidas ou todas elas falharo. possvel simular algumas destas caractersticas atravs de certos truques de programao e tabelas temporrias, mas eventualmente, haver a necessidade de se modificarem os registros um de cada vez, em lote, o que deixaria aberturas para a ocorrncia de falhas. Alm disto, impossvel de se programar um aplicativo Paradox para se recuperar de uma falha de sistema como queda de fora ou danos na memria secundria.

Gatilhos (triggers) e procedimentos (procedures)

Uma Stored Procedure consiste em um pedao de cdigo armazenado em um banco de dados junto aos dados que este contm. Isto permite ao servidor efetuar manipulaes complexas de dados inteiramente no prprio servidor. As vantagens principais disto so que processos ainda mais complexos podem ser delegados ao servidor, e qualquer nmero de diferentes aplicaes clientes podem chamar os mesmos procedimentos. Se o procedimento for modificado no servidor, nenhuma das aplicaes necessitar ser reescrita, desde que a interface do procedimento continue a mesma. Um trigger consiste em uma Stored Procedure que no explicitamente chamado por uma aplicao, mas executado em resposta a uma ao ocorrida com determinados dados, como por exemplo, uma insero de novos registros. A utilizao de triggers permite que voc realize validaes de dados extremamente complexas, sendo que as operaes planejadas ocorrero garantidamente no interior da mesma transao que disparou o engatilhamento . Se alguma das operaes falhar, todas as alteraes feitas por triggers associados a esta operao sero tambm desfeitas (rolled back). O InterBase suporta Stored Procedures que retornam Result sets, os quais so tratados exatamente como tabelas somente de leituras, assim como triggers que simplesmente executam transaes de dados e no retornam nenhum resultado. O InterBase suporta essencialmente um nmero ilimitado de triggers para cada tabela os quais podem ocorrer antes ou depois das operaes de insero, alterao e remoo de registros. Se mais de um trigger associado a uma operao a ordem de execuo pode ser especificada. Triggers podem efetuar mudanas que disparem outros triggers, numa reao em cadeia, mas estas aes em cascata continuaro contidas numa nica transao. O Paradox no suporta nenhum destes conceitos. Todos os processamentos de dados devem ser realizados no cliente. Cada aplicao deve conter a mesma codificao para manuteno dos dados, e cada uma delas deve tambm ser modificada caso o mtodo de manipulao de dados necessitar ser alterado. No existe uma garantia que uma aplicao ser completada uma vez que tenha sido iniciada. Por exemplo a operao de se efetuar uma deleo em cascata de registros detalhe aps a deleo de um registro mestre pode falhar no seu meio, deixando alguns registros detalhe sem serem apagados. Se esta cascata fosse implementada por meio de triggers no InterBase, ou todos os registros ou nenhum deles seriam apagados. Alm disto, numa aplicao Paradox, a codificao para perpetuar a deleo deveria ser escrita em cada uma das aplicaes diferentes que utilizassem os dados do sistema Paradox. Utilizando-se InterBase, por outro lado, a codificao necessita ser escrita apenas uma vez, no trigger. A aplicao simplesmente deleta o registro mestre e o InterBase cuida da deleo dos registros detalhe.

Fazendo a melhor escolha

Escolher entre Paradox e InterBase pode ter implicao importante para o seu projeto. Portanto, essencial saber o que mais adequado em cada situao. A figura 1 mostra alguns princpios gerais que podem ajud-lo a tomar a melhor deciso. Isto so sugestes e no devem ser encaradas como regras. A maioria presume que uma rede estar envolvida. Se voc est implementando um sistema mono-usurio, o Paradox usualmente a melhor escolha. O servidor InterBase local pode ser indicado para um sistema mono-usurio, mas sem os aspectos de concorrncia, as vantagens bsicas do InterBase no estaro sendo utilizadas.

Concluso
importante relembrar que o Paradox e o InterBase so sistemas consideravelmente diferentes, mesmo que o BDE crie uma iluso de semelhana. Esta uma sedutora mas perigosa idia pois converter uma aplicao de um mecanismo para outro (InterBase em Paradox ou vice e versa) envolve muito mais do que uma simples mudana de Alias. Requer na verdade, significativas diferenas de conceito e projeto. Escolher qual sistema utilizar uma deciso crucial que deve ser tomada no incio do projeto. Esta deciso ter um impacto profundo no desenvolvimento da sua aplicao.

Paradox melhor quando...

a aplicao utilizada com menos de 10 usurios concorrentemente dados e estruturas de dados devem ser facilmente modificados por usurios finais a mquina cliente proporcionalmente mais potente que a mquina servidora largura de banda da rede satisfatria velocidade e convenincia so mais importantes que integridade baixa disponibilidade de administradores de rede e BD qualificados somente uma aplicao acessar rotineiramente os dados as aplicaes sero as resp. pela manut. da integridade de dados pequena ou moderada quantidade de dados (< 100 MB)

InterBase melhor quando...

a aplicao utilizada com mais de 10 usurios concorrentemente dados devem ser centralizados, mantidos e protegidos a mquina servidora muito mais potente que a mquina cliente rede est carregada integridade de dados crucial disponibilidade de administradores de rede e BD qualificados vrias aplicaes podero acessar os dados o banco ser o resp. pela integridade de dados moderada a grande quantidade de dados (> 100 MB)

Adaptao livre do artigo InterBase vs. Paradox Delphi Informant Magazine - volume 2, nmero 6, Junho de 1996, Pag. 28-35 Danielle Fortes Lopes - dani@wim.com.br WIM Informtica Ltda.