Empacotando SQL em Views Reutilizáveis no Mysql

porLuis Augusto Moretto

Empacotando SQL em Views Reutilizáveis no Mysql

Construa Instruções SQL reutilizáveis no Mysql com Views

mysql views como componentes reutilizaveis
Mysql Views

Introdução

Em post anterior falamos como otimizar seu MYSQL em nível de configurações. Agora vamos dar umas dicas sobre Views e seu uso.

As Views MySQL são uma maneira de empacotar instruções SELECT. Estas instruções são armazenadas no SGBD em tabelas virtuais reutilizáveis.

Para recuperar os dados faz-se referência a VIEW, ao invés de ter que repetir a declaração SELECT associada.

As Views são mais comumente usadas em conjunto com JOINS, UNIONS, COUNT, COALESCE etc. 

O objetivo deste capítulo é explorar o conceito de visualizações no MySQL.

O Problema

Vamos supor que você queira construir um serviço REST para seu APP. Os dados estão armazenados em um banco de dados Mysql no modelo de dados do WordPress.

Para quem conhece o modelo relacional do WordPress sabe que os dados ficam armazenados com Metadados.

Basicamente tudo é um post. Atributos do POST são armazenados em WP_POSTMETA, WP_TERM tem os termos, WP_TERMTAXONOMY as classificações e finalmente WP_TERM_RELATIOSHIP o seu relacionamento com WP_POSTS.

Exemplo: Se você tem um post do tipo ‘listing‘ que representa um imóvel. Os dados como preço, área total,  número de banheiros, quartos e suites ficam armazenados em WP_POSTMETA. O tipo do imóvel (casa, apartamento, sala comercial etc), assim como sua classificação e atributos (lançamento, churrasqueira, lareira, aquecimento)  em WP_TERM, WP_TERMTAXONOMY e WP_TERM_RELATIOSHIP.

Toda vez que precisar fazer uma consulta de todos os imóveis e seus meta dados será necessário um SQL gigante!!!!!

Além da query de WP_POST será necessário dezenas de subqueries para estruturar a informação. Veja como ficaria o exemplo da query a ser chamada em diversos trechos de código sem a view.

select ID as event_id, a.post_title as tit, post_content as info,
     (SELECT  
                `wp_postmeta`.`meta_value` AS `state`
            FROM
                `wp_postmeta`
            WHERE
                ((`wp_postmeta`.`post_id` = `a`.`ID`)
        				   and (meta_key = 'address'))) as endereco,
	 (SELECT 
                `wp_postmeta`.`meta_value` AS `state`
            FROM
                `wp_postmeta`
            WHERE
                ((`wp_postmeta`.`post_id` = `a`.`ID`)
        				   and (meta_key = 'area'))) as total_area,
	 (SELECT 
                `wp_postmeta`.`meta_value` AS `state`
            FROM
                `wp_postmeta`
            WHERE
                ((`wp_postmeta`.`post_id` = `a`.`ID`)
      				   and (meta_key = 'bathroom'))) as bathroom,
	 (SELECT 
                `wp_postmeta`.`meta_value` AS `state`
            FROM
                `wp_postmeta`
            WHERE
                ((`wp_postmeta`.`post_id` = `a`.`ID`)
                    AND (`wp_postmeta`.`meta_key` = 'suite'))) AS suite
					   -- and (meta_key = 'vcard_email'))) as email
  from wp_posts as a where a.post_type = 'listing' 

Solução

A solução é criar uma view para o SQL acima. Ao invés de redeclarar N vezes todo o trecho de código, se a regra de negócio for alterada, a mudança terá um grande impacto. Com o empacotamento do SQL em uma view centraliza a mudança em um único ponto do sistema.  Exemplo de criação de uma View:
CREATE VIEW
	view_listing
AS
//Meu SQL aqui
Para chamar a view e filtrar segue o mesmo princípio de uma consulta SQL.
select * from view_listing where total_area >100

Happy Coding! 😀