A evolução das minhas consultas SQL

Olá a todos! Sou Líder de Equipe e Desenvolvedor Oracle Sênior, trabalho com OeBS há 12 anos e principalmente escrevo consultas SQL. Gostaria de dizer como minha abordagem para escrever consultas SQL mudou durante esse tempo.





No início havia uma palavra, ou melhor, um pedido. Digamos





select name from user where id = 1
      
      



É quase impossível escrever tal pedido. Funciona igualmente bem em todos os bancos de dados que conheço. E eu só conheço oracle: W Mas desconfio que em outro relacional também vai dar tudo certo.





Então o que aconteceu? Os problemas começaram quando havia duas tabelas:





select name from user u, rest r where u.id = 1 and u.id = r.user_id
      
      



Este código me deu mais perguntas. Por exemplo, como essas tabelas devem ser unidas? Parece que é mais fácil  id = user_id



, mas eu não gostei de algo. Na cláusula where, estava faltando uma separação clara entre as condições de filtro e as junções de tabela. Quando a consulta continha 2 tabelas, ainda era normal, mas quando o número de tabelas chegou a 5, tudo desmoronou. Olhando para a consulta, não consegui entender imediatamente como as tabelas estavam conectadas e se algum link estava faltando. E todos conviveram bem com isso, mas eu não consegui. Um dia, quando era um jovem June, me deparei com a sintaxe ANSI.





select name from user inner join rest on u.id = r.user_id where u.id = 1
      
      



, , SQL . , - . . SQL. - . . ANSI , .





select u.name, r.resp_name 
from user u 
left join resp r on u.id = r.user_id  and r.end_date > sysdate 
where id = 1
      
      



, .  , , .  .  .  with.





select resp_q as (
  select resp_name, userid  
  from resp where r.end_date > sysdate)
 ,main_q as (
   select u.name, r.respname
   from user u 
   left join resp_q r on u.id = r.userid
   where id = 1)
 select * from main_q
      
      



, with “”, . : “ . . . , .”  . WET, .. , .  , . from .  , , with , hint MATERIALIZE. . . , .. + . , , 10 , with.





- . , , , - . , . unit , . . 100, 120. ? … , , , . ( ).





select * from document where xxstorno(id) = 'Y'
      
      



10 . , - . , .  . , , , . , 5-7 , .





with test_case as (
  select 10 id, 'Y' storno from dual 
  union all 
  select 5 id, 'N' storno from dual)
  , run_test as (
    select tc.id, decode(xxstorno(d.id), tc.storno, 'OK', 'Error') result
    from test_case  tc
    left join document d on d.id = tc.id)
 select * from run_test
      
      



, - , . , . , ! , . , . and id = 5--6 7 10 135 1345



  em que diferentes valores foram simplesmente substituídos pela força bruta e o que e como ela deveria retornar com as mãos. Desde aquele dia, escrevi vários desenvolvimentos e para cada um deles já preparei meu próprio roteiro de teste. Eu realmente gostei desse estilo e agora estou tentando incutir isso em meus desenvolvedores. Para que eles não tenham que viajar 12 anos para escrever lindas consultas SQL.





Como resultado, quase nada de novo vem acontecendo no mundo do SQL há muitos anos, entretanto, é sempre bom encontrar oportunidades para melhorar suas consultas.








All Articles