La evolución de mis consultas SQL

¡Hola a todos! Soy Team Lead y Senior Oracle Developer, he trabajado con OeBS durante 12 años y principalmente escribo consultas SQL. Me gustaría contarles cómo ha cambiado mi enfoque para escribir consultas SQL durante este tiempo.





Al principio había una palabra, o más bien una petición. Digamos





select name from user where id = 1
      
      



Es casi imposible escribir una solicitud de este tipo. Funciona igualmente bien en todas las bases de datos que conozco. Y solo conozco a Oracle: W Pero sospecho que en otros relacionales también, todo estará bien.





¿Entonces qué pasó? Los problemas comenzaron cuando había dos tablas:





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



Este código me dio más preguntas. Por ejemplo, ¿cómo se deben unir estas tablas? Parecería que es más fácil  id = user_id



, pero algo no me gustó. En la cláusula where, me faltaba una separación clara entre las condiciones de filtro y las combinaciones de tablas. Cuando la consulta contenía 2 tablas, todavía era normal, pero cuando el número de tablas llegó a 5, todo se vino abajo. Al mirar la consulta, no pude entender de inmediato cómo estaban conectadas las tablas y si faltaba algún enlace. Y todos vivieron bien con eso, pero yo no pude. Un día, como un joven junio, me encontré con la sintaxis 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



  en el que diferentes valores fueron simplemente sustituidos por la fuerza bruta y se veía qué y cómo debería volver con las manos. Desde ese día, he escrito varios desarrollos, y para cada uno de ellos ya he preparado mi propio guión de prueba. Me gustó mucho este estilo y ahora estoy tratando de inculcarlo a mis desarrolladores. Para que no tengan que viajar 12 años para escribir hermosas consultas SQL.





Como resultado, casi nada nuevo ha sucedido en el mundo de SQL durante muchos años; sin embargo, siempre es bueno encontrar oportunidades para mejorar sus consultas.








All Articles