L'évolution de mes requêtes SQL

Bonjour à tous! Je suis Team Lead et Senior Oracle Developer, je travaille avec OeBS depuis 12 ans et j'écris principalement des requêtes SQL. Je voudrais vous dire comment mon approche de l'écriture de requêtes SQL a changé pendant cette période.

Au début, il y avait un mot, ou plutôt une requête. Disons

select name from user where id = 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Il est presque impossible d'écrire une telle demande. Cela fonctionne aussi bien dans toutes les bases de données que je connais. Et je ne connais qu'oracle: W Mais je soupçonne que dans d'autres relations aussi, tout ira bien.

Alors, qu'est-ce-qu'il s'est passé? Les problèmes ont commencé quand il y avait deux tables:

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Ce code m'a donné plus de questions. Par exemple, comment ces tables doivent-elles être jointes? Il semblerait que ce soit plus facile  id = user_id



, mais je n’ai pas aimé quelque chose. Dans la clause where, il me manquait une séparation claire entre les conditions de filtre et les jointures de table. Lorsque la requête contenait 2 tables, c'était encore normal, mais lorsque le nombre de tables atteignait 5, tout s'effondra. En regardant la requête, je ne pouvais pas comprendre immédiatement comment les tables étaient connectées et s'il manquait un lien. Et tout le monde a bien vécu avec ça, mais je ne pouvais pas. Un jour, en tant que jeune June, je suis tombé sur la syntaxe 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



  dans lequel différentes valeurs ont simplement été remplacées par la force brute et quoi et comment il devrait revenir avec les mains regardé. Depuis ce jour, j'ai écrit plusieurs développements, et pour chacun d'eux j'ai déjà préparé mon propre script de test. J'ai vraiment aimé ce style et maintenant j'essaye de l'instiller chez mes développeurs. Pour qu'ils n'aient pas à voyager 12 ans pour écrire de belles requêtes SQL.

En conséquence, presque rien de nouveau ne s'est produit dans le monde SQL depuis de nombreuses années, cependant, il est toujours agréable de trouver des opportunités pour améliorer vos requêtes.