Artigos Delphi Firebird 2.5 - Artigo Clube Delphi 125

Do que trata o artigo

O artigo mostra as novidades da nova versão 2.5 do SGBD Firebird. Inicialmente é apresentado um pequeno histórico de sua evolução e logo em seguida são explicadas as novidades com pequenos exemplos de uso que farão com que o leitor os entenda facilmente.

Para que serve

Demonstrar ao leitor através de exemplos como realizar o upgrade de sua versão atual para o Firebird 2.5, bem como ilustrar todas as suas novidades, fazendo com que o leitor compreenda o funcionamento de cada recurso e possa aplicar em seus sistemas.

Em que situação o tema é útil

Tendo conhecimento dos principais recursos suportados pelo sistema gerenciador de banco de dados, o desenvolvedor pode realizar seu trabalho de forma mais eficaz, reduzindo a necessidade de escrever código desnecessário nas aplicações.

Resumo do DevMan

Veremos neste artigo um pouco sobre o Firebird 2.5, que possui uma nova arquitetura que possibilita uma melhoria de desempenho em aplicativos de banco de dados. Após a leitura, o leitor se sentirá tentado a migrar suas aplicações para essa versão utilizando todas as diversas novidades incluídas.

O desenvolvimento do SGBD Firebird foi iniciado em Julho do ano 2000 a partir do código fonte da versão beta do InterBase 6.0, disponibilizado pela Inprise (Borland) sob licença Open Source. Desde então cinco versões foram lançadas pela sua equipe de desenvolvimento, mostrando uma evolução contínua do produto. O foco deste artigo é mostrar as principais funcionalidades para desenvolvedores adicionadas à versão 2.5, lançada em outubro de 2010, no ano em que o projeto faz seu décimo aniversário. Antes de aprofundar nestes temas, gostaria de mostrar um breve histórico da evolução do Firebird nestes 10 anos.

Na versão 1.0 a maior parte do trabalho foi interna, já que o código inicial não tinha documentação e não chegava nem mesmo a compilar. Uma das alterações mais importantes nesta versão foi a correção de um bug de segurança do InterBase, que foi rapidamente identificado quando seu código tornou-se público.

Na versão 1.5 o código-fonte foi convertido de C para C++. Algumas novidades que apareceram nesta versão foram variáveis de contexto como CURRENT_USER e CURRENT_ROLE, funções como COALESCE e NULLIF, expressões CASE, o tipo de dados BIGINT, melhorias em alguns comandos DDL (CREATE OR ALTER, RECREATE), o comando EXECUTE STATEMENT, as cláusulas FIRST e SKIP e suporte a savepoints e locks pessimistas.

A versão 2.0 introduziu o conceito de tabelas derivadas, cursores explícitos, valores default para parâmetros, as funções IIF, CHAR_LENGTH, TRIM, RDB$GET_CONTEXT e RDB$SET_CONTEXT, o operador IS [NOT] DISTINCT, os comandos EXECUTE BLOCK e COMMENT ON, a cláusula RETURNING, índices definidos por expressões, Collates (PT_BR e WIN_PTBR) para o Brasil, suporte a Unicode, melhorias de performance relacionadas à nova implementação de índices e diversas mudanças no otimizador, backups físicos e incrementais com o NBackup e suporte a plataformas 64-bits.

Nota do DevMan

Tabela derivada (derived table) é o nome dado pelo padrão SQL a uma query usada na cláusula FROM de outra query. Por exemplo: SELECT X.* FROM (SELECT * FROM PESSOAS) X. Neste caso, X é uma tabela derivada.

A versão 2.1 introduziu dezenas de novas funções internas, Triggers de eventos de conexão e transação, tabelas temporárias, Collates customizáveis com CREATE COLLATION, queries recursivas com Common Table Expression (CTE), os comandos UPDATE OR INSERT e MERGE, a função agregada LIST, a possibilidade de uso de Domains em PSQL, a interoperabilidade entre BLOBs e Strings, tabelas de monitoração, o utilitário fbsvcmgr e diversas melhorias implementadas no protocolo de comunicação, melhorando a performance de comunicação cliente/servidor via internet.

Nota do DevMan

Common Table Expression (CTE) é similar ao conceito de tabelas derivadas, porém, o nome da tabela é definido no começo da instrução com a cláusula WITH. Exemplo: WITH X AS (SELECT * FROM PESSOAS) SELECT * FROM X. Com as CTEs é possível fazer queries hierárquicas (recursivas) usando-se WITH RECURSIVE e UNION ALL. Veja mais exemplos no release notes da versão 2.1 na sessão Links.

Diante de toda essa evolução, é importante ressaltar que toda alteração e novas funcionalidades do Firebird são pensadas, levando em consideração dois princípios estabelecidos pelo projeto: compatibilidade e padronização SQL. A compatibilidade é sempre levada extremamente a sério, e dificilmente algo que funciona em uma versão deixa de funcionar em outra, respeitando o investimento feito pelos desenvolvedores. Em relação ao padrão SQL, ele é sempre consultado e analisado em detalhes, e quando possível, as implementações são realizadas com base neste padrão.

A versão 2.5, assim como as anteriores, possui diversas novas funcionalidades. Primeiramente, veremos sobre possíveis problemas durante o processo de migração. Em seguida, veremos sobre a nova arquitetura SuperClassic, que permite melhor aproveitamento de recursos e melhor desempenho em máquinas multiprocessadas, e as alterações diretamente relacionadas ao desenvolvimento. Os exemplos presentes nas listagens foram feitos para o ISQL, mas devem funcionar sem problemas em qualquer ferramenta.

Migrando de versões anteriores

Conforme citado anteriormente, a compatibilidade é levada a sério no Firebird. Infelizmente, às vezes é preciso fazer mudanças que causam certas dificuldades de migração. Antes da versão 2.1 o Firebird tinha importantes bugs referentes a implementação de character sets multibyte herdados do InterBase. Um destes character sets é o UNICODE_FSS, que é usado pelas tabelas de sistema RDB$. O Firebird não convertia, do character set cliente para o UNICODE_FSS, nomes, Strings e código-fonte de objetos durante a execução de comandos DDL e simplesmente gravava os dados, que do ponto de vista do UNICODE_FSS eram inválidos. A partir da versão 2.1 esta conversão passou a ser feita, embora ainda fosse possível a criação de objetos inválidos usando o character set NONE. Para corrigir os objetos gravados de forma incorreta, foi disponibilizado um script que deveria ser rodado após o restore na versão 2.1.

Nota do DevMan

Comandos DDL (Data Definition Language) são comandos SQL usados para a definição dos objetos do banco de dados. Exemplos de comandos DDL: CREATE TABLE, DROP TABLE e CREATE VIEW.

...
Quer ler esse conteúdo completo? Tenha acesso completo