Tipos de dados complexos no PostgreSQL

Este artigo trata do uso de tipos de dados complexos suportados pelo PostgreSQL, versão 9.1, discorrendo especificamente sobre as principais características destes tipos de dados e onde o seu uso é mais adequado.

De que se trata o artigo

Este artigo trata do uso de tipos de dados complexos suportados pelo PostgreSQL, versão 9.1, discorrendo especificamente sobre as principais características destes tipos de dados e onde o seu uso é mais adequado.

Em que situação o tema útil

Ao projetar uma base de dados para uma aplicação, podemos nos deparar com a necessidade de mapear tipos de dados compostos, os quais são um agregado de várias informações distintas, mas que, no domínio do negócio, referem-se a um único objeto de informação.

Neste ponto, cabe ao arquiteto da base de dados determinar a melhor abordagem para converter esta necessidade em um modelo de dados. Certamente existem inúmeras formas de fazê-lo, como tudo no mundo da tecnologia da informação.

Contudo, o arquiteto deve prezar sempre pela melhor solução, usando-se dos recursos mais avançados do SGBD sob o qual o projeto esta sendo desenvolvido.

Resumo DevMan

Cada vez mais se observa muitos projetos de software onde as regras de negócio são massivamente codificadas na camada de aplicação, deixando a base de dados como um mero repositório de informações. O mesmo se aplica a estrutura dos dados complexas que são montadas na camada de aplicação, mas que na base deixam seus componentes espalhados de forma desestruturada.

Esse modelo de desenvolvimento, além de desperdiçar valiosas funcionalidades que os SGBDs modernos oferecem, põe em risco a qualidade da informação, pois ela fica a mercê somente do bom funcionamento do software, sem mencionar a perda de desempenho tida em alguns casos.

No que tange a manipulação de dados complexos, o PostgreSQL 9.1 torna possível a criação e operação de registros, vetores e enumerações nativamente na base, permitindo a transferência de estruturas de dados normalmente mantidas na camada de aplicação para a camada de dados. Ganha-se em flexibilidade, qualidade de informação e de quebra, para alguns casos, melhora de desempenho.

A arte de desenvolver software quase sempre impõe grandes desafios aos profissionais. É algo inerente à própria ciência, uma vez que a tecnologia da informação visa traduzir problemas reais em soluções computacionais, convertendo necessidades de negócio em algoritmos funcionais.

É justamente nesta transcrição de um dado problema do mundo real para seu respectivo mapeamento computacional que a criatividade dos arquitetos de sistemas é posta à prova. Compreender as reais necessidades e expectativas atribuídas pelo cliente ao futuro software não é tarefa das mais fáceis. É preciso um conjunto exaustivo de entrevistas, observações e análises até se chegar ao ponto onde a equipe de desenvolvimento e o cliente dizem unanimemente: “Bem, é isso. Mãos a obra!”.

Uma vez tendo ciência do que deve ser feito, é chegada à hora de definir o “como” deve ser feito. É o ponto onde a equipe de desenvolvimento começa a converter todos os requisitos funcionais e não-funcionais recolhidos até então em modelos computacionais. O domínio do problema, agora compreendido, começa a ganhar traços funcionais.

A complexidade do software, em termos arquiteturais, é definida pelo domínio do problema a que ele se propõe a resolver. Isso é facilmente observado quando se compara o desenvolvimento de um software de controle de tráfego aéreo a um simples web site para uma empresa, por exemplo. No primeiro caso, a exigência de precisão, estabilidade, tolerância a falhas e correção são infinitamente maiores do que os do segundo caso. Além disso, as informações que a aplicação manipula são muito mais complexas e requerem o uso de estruturas de dados adequadas a sua manipulação, que não são exatamente tipos simples, mas agregados de dados ou mesmo objetos na maioria das vezes."

[...] continue lendo...

Artigos relacionados