Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Tipos de dados complexos no PostgreSQL - Revista SQL Magazine 98
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.
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
SQL Magazine 98
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 98
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 98
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.
Desta forma, ao se modelar a base de dados é imprescindível levar em consideração quais são as estruturas de dados que a aplicação irá manipular, prezando sempre pelo uso de todo e qualquer recurso oferecido pelo SGBD que permita aproximar o máximo possível a estrutura real da informação com o seu respectivo mapeamento computacional, quando isso for aplicável, é claro.
Contudo, para que seja possível esta aproximação entre o objeto real e seu respectivo modelo computacional de dados, a escolha do SGBD tem forte impacto. Existem inúmeras opções existentes no mercado, voltados aos mais diversos propósitos, imbuídos das mais variadas filosofias de desenvolvimento e disponíveis aos mais diversos bolsos.
O PostgreSQL, um dos mais consolidados SGBDs open-source do mercado, apresenta-se sempre como uma ótima alternativa para os mais variados propósitos. No que tange a manipulação de estrutura de dados complexas, o PostgreSQL não deixa nada a desejar, oferecendo suporte à manipulação de vetores, matrizes, enumerações, objetos geométricos, tipos compostos e outros mais. Conforme será visto no decorrer deste artigo, quando o assunto são dados complexos, o PostgreSQL mais uma vez deve figurar entre as opções de escolha de SGBD do projeto.
"
Este é um post disponível para assinantes MVP
É 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.
Desta forma, ao se modelar a base de dados é imprescindível levar em consideração quais são as estruturas de dados que a aplicação irá manipular, prezando sempre pelo uso de todo e qualquer recurso oferecido pelo SGBD que permita aproximar o máximo possível a estrutura real da informação com o seu respectivo mapeamento computacional, quando isso for aplicável, é claro.
Contudo, para que seja possível esta aproximação entre o objeto real e seu respectivo modelo computacional de dados, a escolha do SGBD tem forte impacto. Existem inúmeras opções existentes no mercado, voltados aos mais diversos propósitos, imbuídos das mais variadas filosofias de desenvolvimento e disponíveis aos mais diversos bolsos.
O PostgreSQL, um dos mais consolidados SGBDs open-source do mercado, apresenta-se sempre como uma ótima alternativa para os mais variados propósitos. No que tange a manipulação de estrutura de dados complexas, o PostgreSQL não deixa nada a desejar, oferecendo suporte à manipulação de vetores, matrizes, enumerações, objetos geométricos, tipos compostos e outros mais. Conforme será visto no decorrer deste artigo, quando o assunto são dados complexos, o PostgreSQL mais uma vez deve figurar entre as opções de escolha de SGBD do projeto.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Bacharel em Ciência da Computação pela Universidade de Passo Fundo. Desenvolvedor Delphi a 5 anos. Atualmente trabalha com desenvolvimento de integrações de sistemas usando a tecnologia Oracle AIA. Possui sólidos conhecimentos em PL/SQL, programação orientada a objetos e Engenharia de Software.
O que você achou deste post?
Cursos relacionados
Publicidade
